fh1805

Igor, Is auto-updating going to apply to the main PTE code as well or just the configuration files for the external interfaces? regards, Peter

Hi josephm, I think that in v5.0 you cannot easily create a manual slide show. It is a long time since I used v5.0. If you download the latest version, v5.52, it is a very simple set of changes that you need. 1) in Project Options...Main you tick the box "Wait for a keypress or mouse click to show next slide" 2) in Project Options...Advanced you set the mouse buttons to "Next Slide" and "Previous Slide" and also probably want to set the option here to "Always show mouse cursor" so that you can use the mouse cursor to point to items that you talking about. And that's it! PTE v5.52 will install alongside v5.0 and co-exist with it and your product "key" will be automatically detected and used to activate v5.52. The user interface is a little different but I think you will quickly adapt to it. Project files created with PTE versions prior to v5.52 are upwardly compatible but if you save one of them using v5.52 you cannot then take it back to an earlier version. regards, Peter

Dick, You seem to have understood the principle that is giving rise to this perceived problem. regards, Peter

I would be content to leave it as FULLSCREEN; but is BEST FIT a more accurate name for it in English? And it occurs to me that there are actually two nominal sizes involved in this discussion, are there not? - the nominal size at which the sequence is being assembled - the nominal size at which the sequence is going to playback As creators of our sequences we can directly control only the first. For this we need the two input fields already discussed by Jean-Pierre and myself. The nominal size at playback has to be calculated by PTE based upon 1) the information we supplied during the build and 2) the actual resolution of the monitor used for playback. Any solution has to take that into account, surely? regards Peter

Jean-Pierre, Agreed. And this could be achieved by having two extra input fields, as you suggest. I propose they be associated with "Fullscreen". PTE could pre-fill them with the resolution of the detected monitor but the user could change them (using your example, to 1920x1080). "Fullscreen" on its own has no meaning. It says nothing about the size of the actual screen. And then PTE could use these two new values to set the initial size of any of the "virtual objects" - frames, rectangles and mask containers (instead of using the seemingly arbitrary 10000x8000 size). Have we solved it? regards, Peter

Jean-Pierre, You understand, mon ami ! As you say, the inconsistency is in having the frame take a default size of 10000x8000 as shown on the Properties tab. Yes, I know I can get the effect I want by keying in 1280 and 1024 into the fields on the Properties tab. But why do I have to? PTE knows my monitor resolution and it knows what aspect ratio I'm working at (as Cor points out in his post). Why cannot PTE set the frame size correctly automatically, so that 100% Zoom of the frame covers my chosen aspect ratio on my monitor? Why does anybody have to key anything in anywhere? PTE already sets the size and position correctly for the "real image" files. Is it unreasonable for me to expect it to do the same with all the "virtual images"? Is it unreasonable for me to expect PTE to show consistent behaviour? regards, Peter

DaveG, See my bold font in your quote above. PTE is getting more and more complicated to use. It is taking longer and longer to learn how to use the new features. If Igor wants to continue to expand his user base, which I assume is one of his commercial objectives, then he needs to have a product which is easy to use, easy to learn and which produces the best image quality. My argument is not about the technical function of the product. It is about the inconsistency. If I enter the same number values into the Position and Size fields for two objects, one on each of two slides; I expect the two slides to look the same on my system - they don't! If I am led to believe that these numbers are absolute pixels then I expect the images should look the same on your monitor as they do on mine - and you say they don't! This is not consistency of behaviour. This is not "intuitive" usage. regards, Peter

Isabel, When you say "transferring PTE to it" what exactly do you mean: - a PTE created exe of a slide show? - the PTE zip file that was downloaded from WnSoft - something else? What media are you using to do the transfer? - CD? - DVD? - USB memory device? - File sharing on networked PCs? Have you completed the install and updating of your anti-virus software on the Vista machine? Have you re-booted the Vista machine since doing that? I would recommend that you ensure that you have got both Windows Vista and your anti-virus/Internet security software fully installed and updated before you try and load any application software. That's what I did when I got my new PC about 18 months ago. On day one I installed the operating system and Norton Internet Security and then left it hooked up on the broadband link overnight to pull down any "automatic updates" that it wanted to. First thing on day two, I installed these, rebooted and then set about adding the application software. I transferred my PTE zip file from a Windows XP laptop and had no problem. I now regularly transfer the PTE download zip each time I take an new release level of PTE. Again, I have no problems. regards, Peter

Igor/Xaver/DaveG, Please have a look at the attached project file. Extract the zip contents and open the pte file into beta 5. Then do only the following, nothing else: Select slide 2 in the slide list (white on black) and in the O&A window bring up the Size/Position window and observe the Position and Size values of the Black object (0,0 and 1280,1024) and of the white object (100,100 and 640,480) DO NOT CLICK ON POSITION OR SIZE HYPERLINKS Select slide 1 in the slide list (white on blue) and observe the Position and Size values of the Frame (0,0 and 1280, 1024) and of the white object (100,100 and 640,480) DO NOT CLICK ON POSITION OR SIZE HYPERLINKS What question is a new user of PTE going to ask immediately?: He/she will think; I have set up two parent objects: one is a frame the other is a real image file. They have been set to the same size and position using the Size/Position window. I have added exactly the same image file as a child of both parents and have set the position and size of that child to identical values in both slides. He/she will ask: why are the two white images different sizes? Is it unreasonable to expect the appearance of both slides to be the same? PTE thinks it is. To my way of thinking, the outcome of setting up these two slides is totally confusing even for an experienced user of PTE. And the same confusion is going to arise if a rectangle or a mask container is used. These "virtual images" do not behave the same as a real image file. And yet, even experienced users can fall into the trap of thinking of them as real images. If PTE is going to be a truly "intuitive" product to use then an object must behave in an identical manner no matter what kind of object it is. And right now the frame, rectrangle and mask container do not abide by this principle. I am not saying that PTE is not working in accordance with its current design. I am saying that the current design is based on a principle that has a fundamental flaw in it. If I apply exactly the same processing to two different objects I do not get exactly the same outcome - and logically, I should!. This is inconsistent behaviour. It is not "intuitive". regards, Peter Frames_Test_Oct31_2008_9_37_10.zip

Dick, What you describe in your post is exactly what I get, too. As you have seen, there are two pairs of fields that show the size (in pixels) of a Frame, Rectangle or Mask Container: - the two fields in the Properties tab - the two fields in the Size/Position window. My concern is that there exists a point in time in the life of a Frame, Rectangle or Mask Container when these two fields show a different size for the frame, rectangle or mask container. An object cannot have two different sizes - it is an impossibility. The values of the variables representing these fields will be used within the code of PTE to control the behaviour of these objects as we manipulate them in the O&A window. How can we predict with certainty what the effect of our manipulation will be when even PTE does not know with clarity, certainty and lack of ambiguity, the one true size of the object? In my opinion, we no longer need the two fields in the Properties tab. The size (in pixels) of a frame, rectangle or mask container that we, as users, understand is correctly displayed in the Size/Position window. This should be the only place where this information is displayed and modified. regards, Peter

Igor, The problem can be demonstrated very simply by following these simple steps using beta 4: File...New Project Options...Screen...Fullscreen Project Options...Screen...5:4 PC Add an image file that is 1280x1024 (the size of my monitor) Objects & Animations Add a Frame as an independent object (not a child of the image) Open the Size/Position window Select the image file Click on the Size hyperlink (the values are 1280 and 1024) Select the Frame The green box that shows the size of the frame is around the edge of the image. The frame appears to be 1280x1024 The values in the Size/Position window are still 1280x1024. The frame appears to be 1280x1024 Switch to the Properties tab The frame size is (in my case) 10000x8000 Now click on the Size hyperlink (the values change to 10000x8000) There can exist a point in time in the life of this frame when PTE thinks it is two different sizes. In the Size/Position window it thinks it is 1280x1024. In the Properties tab it thinks it is 10000x8000. If I do not change the Properties fields to be 1280x1024 then PTE, in different parts of its logic, will use different sizes when processing this frame and the end result willl be unpredictable from my point oif view. In order to get predictable behaviour I must first set the Frame size in the Properties tab to be 1280x1024. Shouldn't PTE set the default frame size in the Properties tab to be the same as the Fullscreen resolution size? And because the Frame is just a special case of a Rectangle, the same problem occurs with rectangles? The problem with Frames would be completely eradicated if the Frame was a transparent gif or png file instead of a zero opacity rectangle. regards, Peter

DaveG, This is a beauty. You have to first enter a non-zero positive number before you can enter a negative number! But you can enter negative numbers and they have the proper effect for frames, rectangles and image files. regards, Peter

Igor, it was an attachement to an e-mail that JPD sent you, copy to me and Gerard Desroches. Sent on Wednesday 29 Oct at 12:19 Peter

Igor, Have a look at the image file below. It is a screen shot of JPD's project file and it shows that his blue rectangle has two different sizes in PTE. The Properties tab shows its size as 640x480. The "Size/position in pixels..." window shows its size as 960x720 pixels. It cannot have two different pixel sizes - this is impossible. It is either one or the other. But because the size is held in two pairs of fields, the way PTE then behaves is going to be different depending upon which pair of fields you use to get the pixel x pixel size of this object. It is this difference in sizes that has caused the positioning error. regards, Peter

One final thought from me: In v5.6, Mask containers are also a kind of system generated frame. How many unexpected anomalies are lying in wait for us all with these? Proceed with extreme caution my friends, especially if you are trying to get precise position on all resolutions of playback monitor. regards, Peter

I think DaveG has isolated the extent of the problem here. The error seems to occur only to children of a Frame. And that has to be because PTE has got two different sets of size information about the frame. The subsequent behaviour of PTE, in respect of the processing of the children of the frame, is unpredictable because we do not know which set of sizing data PTE will use. The Frame is an artificial construct from within PTE. It is not a real image file; it is just a generated rectangle of zero opacity. The red, blue and green images in JPD's example are also artificially constructed rectangles and not real image files. I'm not a betting man but I'd be willing to wager that, if JPD re-created his experiment using real image files of the same size as his rectangles, then he would get a different outcome - and probably the outcome that he was originally expecting. And the reason I'm willing to wager? I have just done that very experiment with real image files. Sure enough, the 100x100 pixel offsets now position the children exactly where they should. Frames and rectangles whilst appearing to be like other image objects are most definitely not. They have proven that they can be a source of confusion even for seasoned veterans of this software. How much more confusing will they be to a novice user? I suggest that the frame function in PTE be replaced by a transparent gif or png file, the master copy of which is held in a PTE system folder and a working copy of which is placed in the project folder along with the pte file when the pte file is saved. This will have the effect of making the use of frames identical to the use of all other objects. Quite what the solution is for coloured rectangles, I'm not sure. I'll leave that one for Igor and his team to resolve. Thanks to all who have contributed to this discussion with their thoughts, ideas and the results of their own experimentation. It demonstrates very clearly the benefit that can be derived from participation in a forum such as this. regards, Peter

Dick, That is exactly the point I was making. If you look at the size information for the frame in the Properties tab it shows as 10000x8000 whereas in the "Size/position in pixels..." window it shows as the more logical 1280x1024. If you now add a child image to the frame, and try and position and size the child via the "Size/position in pixels..." window, the child behaves not as though the frame were 1280x1024 but as though it were 10000x8000. An item with two different size values that can influence the behaviour of PTE in two different ways is a recipe for massive confusion; as the discussion on this topic demonstrates only too clearly! There is a major bug of some sort here! regards, Peter

It is an unnecessary complication if we have to introduce an artificial object, the transparent frame, simply to get the top-left corner of one object positioned at a precise horizontal and vertical offset from the top-left corner of it's parent object when the Position coordinates are supposed to do that very thing without the need for the additional frame. I repeat: there is either a bug in the code or a flaw in the design. We should not have to program our way around this problem. It needs fixing! regards, Peter Edited 30 Oct 2008: See this post http://www.picturestoexe.com/forums/index....ost&p=58292 for the resolution of this problem.

Why should I have to do something which is counter-intuitive? What could be simpler than to add a child to a parent and say that I want the child's top left corner to be 100 pixels to the right of and 100 pixels down from the parent's top-left corner. It should not matter what size the parent is. It should not matter what size the child is. It should not matter where the parent is relative to any other point of reference. 100 pixels right and 100 pixels down should always be 100 pixels right and 100 pixels down. It should never come out as 130 pixels right and 130 pixels down (or whatever the actual wrong offset is) The difference between us is that you are thinking of a way to get the software to do what you want even if that means doing something additional; I am wanting the software to do what I think it should be doing based upon my understanding of the effect of the input field values. And until we get PTE behaving in a more intuitive manner it will always seem like an over-complicated piece of software to the newbies. I believe that JPD has identified either a bug in the code of PTE or a deficiency in the design of this function. Yes, there are workaround options; but that is what they should be seen as. The root cause needs to be identified and fixed. regards, Peter

DaveG, Please see my post here: http://www.picturestoexe.com/forums/index....ost&p=58265 I believe that what is being seen in JPD's simple example is a bug in the working of "Size/position in pixels...". A 100 pixel offset should always be a 100 pixel offset. And in this case, one of them isn't. regards, Peter

How does "Size/position in pixels..." window work? These notes are written for v5.6 beta 4. You can use this feature for any object that you place into a slide using the O&A window. The button to open this feature's window is found on the Common tab of the O&A window. Clicking on the button brings up a little floating window. This window has two hyperlinks: Position and Size and two pairs of input fields. The Position hyperlink, when clicked, will reset the Position coordinates (the two input fields to the right of it) to the value 0,0. These coordinates define where the top left corner of the object will be positioned. If this object is a child of some other object then the coordinates will be applied as an offset from the top-left corner of the parent object. If the selected object has no parent object then the coordinates are applied as an offset for the defined display area. This will be determined by the choice of mode (Fullscreen or Windowed) and the choice of Aspect ratio taken from the Project Options...Screen tab. The Size hyperlink, when clicked, will set the selected object's size to its actual pixels - and these values will appear in the two fields immediately to the right. All four coordinate values can also be adjusted using the up/down increment buttons or by selecting and overkeying in the usual way for data entry into a field. regards, Peter P.S. Clearly this is a candidate for a new FAQ. When v5.6 goes final I'll make it one.

As this discussion is now about the effects of the "Size/position in pixels..." window could we please use the thread that I have set up for that purpose? Thanks in anticipation... Peter

DaveG, Not if you add it as an independent object, it doesn't (using v5.6 beta 4 in my case). It comes in as visually fitting the screen definition (i.e. it is "Fit to Slide") but its absolute size is 10000 x 8000. Watch the vales in the Properties tab of O&A. If you then add a child to this Frame, the child is sized to the absolute parent and not to the visually reduced parent. That was the fundamental point I was missing. After adding the frame it is necessary to change its size in the Properties fields. Then, and only then, will any added children assume the correct proportions. regards, Peter

Hi DaveG As JPD has pointed out in his reply, your understanding is not correct on this point. A Frame and a Cale do work the same in terms of automatically resizing to the actual monitor resolution on which the sequence is being played back. But the difference comes when wanting to reduce the entire sequence down to 90% of its size in order to fit into the TV Safe Zone. With the Cale all that you need to do is replace the Cale file (it is an actual image file) with one that is 90% of the original in size (i.e. 10% smaller), open the pte file and create the DVD-Video file. With a Frame you would have to open the pte file and manually resize each Frame on each slide - a very time-consuming task! As to your other points, you are now asking about the practicalities of how things work. That is the aspect that I am now researching. I understand the basic principles but now I must understand the practical implementation of them and the user interface requirements of them. As my knowledge and understanding rises I will ensure that it gets published on the forum. But I anticipate this could be a long learning curve. regards, Peter

I said I was missing something fundamental. And now I've found it! I needed to define the size of the Frame in its Properties tab. Having done that, everything starts to work as I expected it should. Now to get on with the tests! Sorry to have bothered you all this morning. regards, Peter