I was being proactive.  Depending on what your stack is doing it may
not affect you.  I saw very little difference after adding an idleRate
of 1500 (was noticeably slower at updating the URL when set to 3000).

If your stack has lots of groups and other elements that require
resizing or repositioning then you will likely want to make your idle
statement as efficient as possible.



On Fri, Jun 25, 2010 at 12:26 PM, Jerry Daniels <[email protected]> wrote:
> Simon, I kept my idlerate at the default and have no problems so far. Where 
> did u see slow down?
>
> Best,
>
> Jerry Daniels
>
> Join the Rodeo discussion:
> http://rodeoapps.com/rodeo-discuss-among-yourselves
>
> On Jun 25, 2010, at 9:36 AM, Simon Lord <[email protected]> wrote:
>
>> Jerry, just be sure to set your idleRate to 1500 so as not to slow
>> down the overall experience of your stack.  I didn't show that in my
>> earlier post.  :)
>>
>>
>>
>> On Fri, Jun 25, 2010 at 10:22 AM, Jerry Daniels <[email protected]> wrote:
>>> Simon,
>>>
>>> I just tried this in the Rodeo embedded web browser and it works every 
>>> time! Amazingly wonderful hack that causes no side-effects that I can 
>>> perceive. Much better than my earlier hack, which required more care and 
>>> feeding. Your approach here is easily implemented and maintained.
>>>
>>> Bravo!
>>>
>>> Best,
>>>
>>> Jerry Daniels
>>>
>>> Follow the Rodeo discussion:
>>> http://rodeoapps.com/rodeo-discuss-among-yourselves
>>>
>>>
>>>
>>> On Jun 24, 2010, at 3:59 PM, Simon Lord wrote:
>>>
>>>> Actually, I got it working just a few moments ago by adding an idle 
>>>> statement:
>>>>
>>>> on idle
>>>>  if the short name of this cd is "iBrowser" then
>>>>  end if
>>>> end idle
>>>>
>>>> That's all I did.  Now browserNavigateComplete is actually getting
>>>> trapped.  Not sure of the reason but without the idle statement
>>>> running I can't do anything.
>>>>
>>>> Now I'm trying to see if I can get browserClick to work.
>>>>
>>>> On Thu, Jun 24, 2010 at 4:47 PM, Bob Sneidar <[email protected]> wrote:
>>>>> I worked with revbrowser for a bit and made some inquiries. The 
>>>>> revbrowser is not a proper Rev object. What it does is "draw" the video 
>>>>> within the bounds of the rect you define. There are no rev events it will 
>>>>> process. Anything happening within the bounds of that rect are ignored by 
>>>>> Rev. That is why the RevBrowser example draws the rect inside a Rev 
>>>>> window, with other controls outside the rect of the video.
>>>>>
>>>>> I wanted to make a full screen video that went away once the user clicked 
>>>>> on the video, but alas, NO MOUSE CLICKS! No events inside the rect are 
>>>>> processed, EVEN if there is a rev object "behind" the video rect! See? 
>>>>> There is absolutely no interaction with the video rect at all.
>>>>>
>>>>> Bob
>>>>>
>>>>>
>>>>> On Jun 24, 2010, at 12:27 PM, Simon Lord wrote:
>>>>>
>>>>>> I've posted a JPG of the issue here:
>>>>>>
>>>>>> http://www.marelina.com/miscellaneous/bad-url.jpg
>>>>>>
>>>>>> This stack is built off the sample browser stack which comes with
>>>>>> RunRev.  I have pretty much everything I need except for this
>>>>>> insidious issue.  As long as the mouse is within the bounds of the
>>>>>> revBrowser display then the URL *never* gets updated.  I've tried a
>>>>>> multitude of methods to try and trap the mouse position, load success
>>>>>> etc.  Nothing is working.  The only way to get the URL to update is if
>>>>>> I move the mouse outside the red bounds—and that's just a bad
>>>>>> solution.
>>>>>>
>>>>>> on idle, mouseWithin, mouseLeave, mouseEnter etc.  None of these is
>>>>>> triggered while the mouse is within the revBrowser.  I can't even get
>>>>>> code to execute when the loading is successful.  It's really just
>>>>>> plain bonkers.
>>>>>>
>>>>>> Any ideas?
>>>>>> _______________________________________________
>>>>>> use-revolution mailing list
>>>>>> [email protected]
>>>>>> Please visit this url to subscribe, unsubscribe and manage your 
>>>>>> subscription preferences:
>>>>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>>>
>>>>> _______________________________________________
>>>>> use-revolution mailing list
>>>>> [email protected]
>>>>> Please visit this url to subscribe, unsubscribe and manage your 
>>>>> subscription preferences:
>>>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>>>
>>>> _______________________________________________
>>>> use-revolution mailing list
>>>> [email protected]
>>>> Please visit this url to subscribe, unsubscribe and manage your 
>>>> subscription preferences:
>>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>
>>> _______________________________________________
>>> use-revolution mailing list
>>> [email protected]
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>
>> _______________________________________________
>> use-revolution mailing list
>> [email protected]
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
> _______________________________________________
> use-revolution mailing list
> [email protected]
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to