Cedric Dawnhawk

Yes I had actually already found that there is no problem if transitions are disabled. This ties up with what I said in my most recent post that it appears that the show jumps to the right time but the transition is not executed. If no transition then no problem. I hadn't tried mouse control but it doesn't surprise me. I also pointed out in a previous post that if there is animation on the slide with any keyframes later than the transition time the problem does not occur. If all keyframes are within the transition time then it does. I'm sure if Igor and the team look at the code, the explanation will be clear. Andrew

Further investigation shows that in pause mode the forward jump is to the end of the transition to the next slide. The reverse jump is to the end of the transition to the previous slide. In play mode the forward jump is to the beginning of the transition to the next slide. The reverse jump is still to the end of the transition to the previous slide. For pause mode this makes sense - you need to jump to the end of the transition otherwise the slide will not be visible and the sequence is not running so it won't be revealed. However I can't see the logic for play mode. I would suggest that both jumps should be to the beginning of the appropriate transition then the transition will occur to the new slide as the sequence runs. The exception to the above is if the reverse jump is to the first slide. In this case the jump is to the start of the transition to the first slide, whether in pause or play mode. Again this doesn't seem logical and I don't see why slide 1 can't follow the same logic as the others. I think this is the second 'bug' that Peter reported. Coming to the original bug, it appears that after the right arrow key has been pressed and nothing seems to have happened, the sequence has in fact jumped to the time corresponding to the end of the transition to the next slide. However for some reason the transition is not executed so nothing happens. You can show this by pressing play after the first right arrow key press. The correct slide immediately appears and the time to the start of the next transition is the "fully visible" time of this slide. Andrew

Igor - Pause the sequence and use the right arrow key to go to slide 6. Use the left arrow key to go back to slide 4. Then use the right arrow key and I hope you will see the problem that on the second press of the arrow key the show jumps to slide 6, not slide 5. Andrew

Thanks for your confirmation Peter. I tried it with "Wait for a key press" checked, and it still seems to occur. Andrew

Although I appreciate everybody's suggestions I did originally ask for anyone to try to reproduce the fault. As far as I can see only Xaver has done this. I have attached a project file ShowControlBugTest_Aug3-2012_14-34-08.zip which demonstrates the fault on two of my computers. Whilst putting the demo together I did notice that if an object on a slide has two keyframes, one of which lies inside and one outside the transition time to the slide, then the fault does not occur.

I can't see why it should be affected by old hardware. I don't think it is speed issue as the sequence is paused when the fault occurs. In fact the fault doesn't occur when the sequence is running.

Possibly there are other specific option settings besides the ones I noted that are needed to cause the effect. I have observed it on two separate computers. Maybe someone else could try and reproduce it?

I wonder if anyone can confirm a bug or at least an anomaly in v7.07? In Project Options do not show the navigation bar but do allow control of the show using the keyboard. Launch a preview of a show, pause it with the space bar or pause/break key. Move up the slides with the left arrow key and the slides display as expected. Now press the right arrow key. Nothing happens. Press again and the slide changes, but to the one after the next ie it skips one. This behaviour does not occur if the show is not paused. Nor does it occur if the 'show navigation bar' option is checked.

Maureen: Thanks for your suggestion Maureen which I tried successfully in v7.0.4 so no need to double check! I can see it might be easier to minimise the window than to Alt Tab to the sequence. However having the title bar displayed does tend to spoil the appearance of the menu. Also if you have minimised the menu in order to reveal the sequence, then at the end of the sequence I presume the desktop is revealed briefly whilst you restore the menu window from the task bar. One thing I did discover was that if I ran in windowed mode but without a border (so the title bar didn't spoil the menu) the offending Proshow Producer sequences started and appeared correctly over the PTE menu. I tried this a few times and it seemed to work consistently so maybe this is the answer! Yachtsman1: I downloaded your beginners guide to menu production and found it very interesting. I usually add the "Run application..." action directly to a text object that shows the title of the show, rather than using a button. Andrew

Sorry for the delay in responding to your helpful comments. I was expecting an email notification when there had been replies. Must have forgotten to check an option! Further investigation shows the problem is not even consistent. Sometimes the Producer show launches normally, sometimes there is a 'flash' and the sequence launches behind the menu and sometimes it just launches behind the menu with no flash. One other thing is that the Producer sequence does take the focus for keyboard input even if visually it is covered by the menu. Pressing Esc closes the Producer sequence not the menu. I ran the show from the PTE menu but for the Producer sequences I clicked the link on the menu, then held the Alt key down with another finger poised over the Tab key, waited for the flash or the start of background music, then quickly tabbed to the Producer sequence, hoping the audience didn't notice. If you have to do this, make sure no applications other than the PTE menu are running, otherwise tabbing is more tricky. I tried PlayView and it doesn't seem to have a problem with the Producer sequences as Nobeefstu suggested. However it does have limitations in terms of the audience being able to see the full programme. It would also be nice to rename the entries in the list from the name of the exe file to the correct title of the sequence, though I suppose it would be just as quick to rename the exe files themselves! I had a quick look at the other suggested solutions, but they are a bit pricey for our camera club. Anyway thanks for the response

I am creating a menu in PTE for an AV show which contains some sequences created by other people with Proshow Producer. I am using the Run Application or Open File... action to open the Producer exe file. When the Producer sequence starts, there is a brief 'flash' of the taskbar etc and then the Producer continues running behind the PTE menu ie it doesn't seem to take the focus. The only way round this that I have found so far is to quickly Alt Tab to the Producer sequence as soon as I see the 'flash'. I am using PTE 7.0.4 (although it seems to do the same with an earlier version) and I have unchecked 'Use Hardware acceleration (DirectX)'. Does anyone know a way round this? I don't have access to Proshow Producer so I don't know whether there may be some option that would sort it out.

I found a confusing issue in v7.04 with recording comments directly to slides. To reproduce the issue do the following: 1. Select a slide, Click Add Sound or Voice | Record Voice Comment. Record then click Save and Exit. 2. Select the same slide, Click the Add Sound or Voice button (now labelled with the file name) then Record Voice Comment. The filename and the path show the previously recorded sound file. Record another comment and click Save and Exit. I assumed this would overwrite the previous sound file but it doesn’t. I tried browsing for and selecting the original file and confirming yes to replace it before recording the new comment. The original was still not replaced. What seems to happen is that temporary hidden sound files are left in the selected folder. If the original file is not supposed to be overwritten then a message stating this would be useful, and the dialog saying the file will be overwritten shouldn’t really appear. Or I am missing something?

Phil: Thanks for confirming it is my icon combined with Avast and PTE V7.0.1 that is the problem. The answer is probably to redesign the icon and try again. It wasn't very brilliant anyway but I've been using it a while. Peter: I did try using another version of the icon with a different name but it still didn't work. I don't really know how virus scans work but I presume it is based on sequences of bits. If so I suppose an icon could just coincidentally contain the same sequence as a virus. It does seem to be a specific problem with Avast. You say AVG doesn't pick anything up and ZoneAlarm, that I use on my main PC, is also unconcerned. Thanks both for your help Andrew

I am pretty convinced it is using my own icon that causes the problem. I created a new exe without ticking the box and it worked. I went to back to the project ticked the box and selected my icon and made a new exe and it failed. However where we may differ is that when I said my icon, I literally meant one I had designed myself. From the description of your tests, are you using the icons in PTE\Main folder? If you are interested I've attached the icon that seems to cause the problem. Andrew AVIconXP.ico

Thanks for that information which confirmed that I did have the latest Avast versions. I had originally created the exe sequence file on another computer and then copied it to a laptop which has Avast installed. I decided to make a new test project, using PTE on the laptop, and create a test exe file. This ran with no problems as you said! After further investigation I found that if I used my own icon for the exe file (Project Options | Assign icon...), Avast picked up a false virus. I think this might be one for Igor! I have submitted the exe file with the false virus to Avast, so hopefully they will sort it out in a future definition file. Andrew

Although the posts suggest this problem has been fixed, I still seem to be suffering from it. I have just installed the free version of Avast and if I try to run a v7.0.1 PTE sequence I get a (false) detection of Win32:Malware-gen. I have updated the Avast virus definitions and program and reported it as a false positive. Could any other user who is not having problems, check their Avast versions? Mine are: Engine and virus definitions: 111029-0 Program: 6.0.1289 Andrew Chadwick

Thanks for the quick response.

Although you may have meant to say "up to" (which also is not strictly true - it can be far more than this) your post says "WAV files take up 10 times the space as MP3" I didn't "spring" from anywhere - I have been a member since 09 February 05 and browse the forum quite often. I am not trying to score points, but I do think what is posted should be accurate and not mislead other readers.

To be strictly accurate, the size of an mp3 file is not necessarily 10 times less than a wav. It depends on the amount of compression used.

I have the desktop extended horizontally across two monitors. If the objects and animation window is positioned in the right monitor, when I select the opacity slider, it appears at the far right of the left monitor instead of immediately underneath the opacity text box. The vertical position however is correct. I am using 6.5.5 and Windows XP SP3. I don't think this has been cured in 6.5.8 and suspect it occurs in version 7, although I haven't tried. Maybe someone could test this for me?

I think all the observed behaviours, both in pause mode and play mode and switching between the two can be summarised in two simple rules (as I am sure Igor would confirm). To apply the rules you need to know which is the 'current' slide. This is found by comparing the time from the start of the sequence with the sum of the individual "display slide for" times for the slides. For example if the times for the first three slides are 5s, 7s and 9s then between 0 and 5s slide 1 is the current slide, between 5s and 12s slide 2 is the current slide etc. 1) If a backward command occurs, jump to the the previous slide at a point at the end of the transition to this slide. 2) If a forward command occurs, jump to the beginning of the next slide. Note that if there is a transition to this slide, the next image may not be visible after the jump, as the transition will only just have begun. Drawing a diagram helps! One day I'll get round to making a sequence. Cedric

There needs to be a transition of some sort between the slides to observe the effect. Yes it is the same PC - I have 4.47 still installed. As I remarked I think this difference is a deliberate 'improvement' whereas the delay or double-press seems like a bug to me. I agree - sheer laziness on my part but updates do seem to come out so frequently. I have updated to v5.6.4 and the symptoms are the same. What you describe (TWO presses of the left or right arrows in pause mode) is what I am experiencing.

In v5.6.1 if the option "Project Options | Advanced | Permit Control of show using keyboard" is checked, the slide transitions can be controlled by the left and right arrow keys. Pressing the keys when the sequence is running moves backwards and forwards as expected. If the sequence is paused (using space bar or Pause key) the right arrow key moves forward as expected. However the first press of the left arrow key is ignored. Subsequent presses moves backwards as expected. The same delay occurs in reverse. The above also happens if using the mouse and navigation bar. This does not occur in v4.47. Further investigation shows that in v5.6.1 in play mode the forward jump is to the beginning of the transition to the next slide. In pause mode the the forward jump is to the end of the transition to the next slide. The reverse jump is to the end of the transition to the previous slide whether in play or pause mode. In v4.47 in both play and pause mode the forward jump is to the beginning of the transition to the next slide. In pause mode the sequences runs briefly to the end of the transition before pausing again. The reverse jump is to the beginning of the transition to the previous slide whether in play or pause mode. Again in pause mode the sequences runs briefly to the end of the transition before pausing again. Can anyone confirm/explain the delay effect in v5.6.1? Presumably the difference in jumping behaviour between v4.47 and v5.6.1 is an intended feature which probably does have some logic to it. Cedric

Xaver Thanks for defending my corner in my absence! Cedric

Thanks for confirming the bug is still in v5.6.3. How do I report it officially? You say "Apart from this bug, scaling is done relative to the total time the slide is to be seen (display time + transition time) ..." This is not strictly true. With scaling on, set a keyframe at the end of the previous transition, then change the previous transition time. The keyframe remains at the end of the previous transition which is no longer the same percentage of total time. Similarly keyframe at start of next transition/change next transition time. I agree this feature is probably not very useful so it's all rather academic!