Bug hunting visual effect

[doobox]

Hi there,

I have been scratching my head for quite some time over this one.

I am not getting the expected result from a visual effect, though i can not replicate the bug in a simplified stack, so it must be unique to my project.

Here is the tail end of my handler where i want to move to another card with a visual effect :

Code: Select all

   if not(pPhotoData is empty) then
      unlock screen -- just in case (no joy)
     // answer number of lines of the pendingMessages -- yields 0
      visual effect "scroll up" slow
      go card "photoCrop" -- the above effect is not seen
   end if
end renderNewGroup

Now i don't see a visual effect when the script moves to the card "photoCrop", but it is obviously being stored as returning from card "photoCrop" shows the visual effect stored earlier in renderNewGroup handler.

So what could be stopping it from executing where it is meant to, when going to the "photoCrop" card

The only thing i can think could be making it behave like this is the fact i have just come out of a mobilePickPhoto operation, but that is like 200 lines earlier, I do loads of stuff after that operation.

Really i am just hoping this screams a certain something at someone, like is "some arbitrary property" set to true at that point in the handler "that will break it"....

[dunbarx]

Hi.

Any chance that there are additional "lock screens" queued? These build up and sometimes you never know. Each "lock" must be paired with a corresponding "unlock". Or you at least need to unlock more than you have locked.

Craig Newman

[doobox]

I did not realise that they had to be paired like that Craig.

Your right.. I just did :

Code: Select all

   if not(pPhotoData is empty) then
      unlock screen
      unlock screen
      unlock screen
      unlock screen
      visual effect "reveal up" slow
      go to card "photoCrop"
   end if

And now it works.

Now to find the real bug.. Where am i missing an unlock
Thanks a million.

[doobox]

Found the culprit, but no idea why its not unlocking as expected.

If i remove the lock and unlock lines from this handler, i don't need any unlock lines in my handler thats changing the card with effect, so i can only assume this is the culprit.

Code: Select all

// ===== PICK NEW PHOTO FROM CAMERA OR LIBRARY =======================
function pickNewPhoto pFromLocation
   lock screen
   set the name of the templateImage to "temp"
   mobilePickPhoto pFromLocation, 320, 320
   set the imagedata of image "temp" to the imagedata of image "temp"
   put the text of image "temp" into tPhotoData
   delete image "temp"
   unlock screen -- culprit never unlocks for some reason
   return tPhotoData
end pickNewPhoto

[doobox]

Oh my.. it actually is not the locks that are the issue.

I thought it was fixed, but what i was seeing was the photo picker sliding down to reveal the new card already in place.
I can still see the bug if i pick a huge image, so it takes long enough to load that the picker has disappeared.
In this case i still see the card switching without the visual effect.

So it does not look to be related to locks as i can still see the bug if i do :

Code: Select all

   if not(pPhotoData is empty) then
      unlock screen
      unlock screen
      unlock screen
      unlock screen
      unlock screen
      unlock screen
      unlock screen
      unlock screen
      visual effect "scroll up" slow
      go to card "photoCrop"
   end if

[dunbarx]

Hmmm.

Put a line in your working code just before the "go" command":

answer the lockscreen

Is it indeed "false"?.

Craig

[doobox]

Yep, its false.

I also thought about moving controls, as the mobilePhotoPicker looks to be just about finished sliding away at this point.
Not sure it would make the list but this yields empty also :

Code: Select all

   if not(pPhotoData is empty) then
      answer the lockscreen -- false
      answer the movingControls -- empty
      visual effect "scroll up slow"
      go to card "photoCrop"
   end if
end renderNewContactGroup

I guess the photoPicker is non blocking..?
But i am wondering if it could be playing a part here.

The docs say that a visual effect will be saved until the next card move. Or until the currently executing handlers have finished executing.
At this point the only thing that can be seen as executing other than the handler its self is the photo picker.

The fact that returning from the new card, shows the effect, shows it has indeed been saved "until the next card move" BUT the move to the new card is really the next card move after i issue the effect.
So i am at a bit of a loss why this first card move after the effect is issued is not honoured.

[doobox]

Archhh.. even this does not show the effect, but saves it until the return from the new card.

Code: Select all

   if not(pPhotoData is empty) then
      send movecard to this card in 5 seconds -- just in case there were unfinished handlers
   end if
end renderNewContactGroup

on movecard
   visual effect "scroll up slow"
      go to card "photoCrop"
end movecard

[doobox]

I was barking up the wrong tree i think.

If i remove the script from the second card i am moving to i see the effect just fine.

I have a preOpenCard handler in the new card that does quite a bit before the card opens (this is obviously causing issue).

Question is, how can i work around it.
I seem to remember a tip for loading all cards at the time the stack opens (that means i forgot that tip).

Not sure that will help me though, as i still need to do quite a bit of processing in the preOpenCard handler in the new card when ever its opened.

[doobox]

Wey hey.. got there in the end..

In the new card i was creating a scroller in the peropencard

You can't...at least not, and expect the visual effect to work.

Moved it to open card and alls is well at the mill

Code: Select all

on openCard
   // create the scroller control
   mobileControlCreate "scroller", "photoScroll"
   put the result into sScrollerID
   // set the properties of the scroller
   mobileControlSet "photoScroll", "rect", tScrollerRect
   mobileControlSet "photoScroll", "contentRect", tContentRect
   mobileControlSet "photoScroll", "visible", true
   mobileControlSet "photoScroll", "scrollingEnabled", true
   mobileControlSet "photoScroll", "vIndicator", true
   mobileControlSet "photoScroll", "vscroll", tContentRect / 2
   mobileControlSet pName, "canBounce", true
   mobileControlSet pName, "delayTouches", true
   put the height of image "test.jpg" /  2 into tHalfHeight
end openCard

[Adrian]

Glad it's all working, but I'm sure I create scrollers in preOpenCard and don't have your visual effect problem, so I wonder if something else is afoot?

I have, though, on many occasions shared the frustration of locks/unlocks seeming to get out of sync: it can take ages to track down, as you've found!

One thing that may well be nothing to do with the problem, but which puzzled me a little, is having the mobilePickPhoto within a "locked" section. Isn't this a bit strange, given that the point of locking is to stop things appearing on the screen until the unlock?

Cheers,

Adrian

[doobox]

Thanks adrian. But it does seem in this case that creating the scroller in the pre open card while listening for the scroll event in the card script its self was the issue.
I can replicate the issue by moving it in and out of the pre open card handler.
At least moving the creation to the open card solved the issue.
I am on 6.5 rc3 and have not tested in a stable version mind.

There were definitely no locks active at the point of moving card.

[MadManSoft]

I seem to be having a similar issue, except it's going from a screen with a scroller to one that doesn't have one.

It's just pops the other card, no visual effect. Going back works as expected.

I'm deleting the scroller before issuing the go to card command, but still no dice.

It works fine on the desktop (Mac) without the scroller present.

Has anyone else seen this?

[[-hh]]

..........

[jacque]

There's a new-ish syntax for visual effects, so try that one instead:

Code: Select all

lock screen for visual effect
  go cd x
unlock screen with visual effect dissolve

The older syntax that couples with "go" still works sometimes, but the recommended way is this one, which takes into account the new caching scheme. RR is very good about efficiently managing visual effects and transitions, so you shouldn't need to write a long handler to manage it yourself. If the above doesn't work, then I'd say it's a bug.