I tried this a bit, and it looks like the engine does resize the screen, but
does not update the contents of the windows at the same time, but only a cycle
later. that produces a very choppy resize visual :(
Maybe a bug report could help? After all, the runrev guys are supposedly
changing around visual stuff right now anyway...
Other things i experimented with (besides lock screen):
remove lock screen from the datagrid:
edit script of button id 1005 of stack "revDataGridLibrary"
handler "resizeToFit"
comment out the lock screen
using a field --> same problem, so it's not a datagrid slowness
flush events, so that pent up resizes do not clog down the handling of events,
doesn't change anything it seems: get flushEvents("all")
wait with messages, so other events can interfere while resizing (most likely
not helpful, but you never know).
On 31 May 2011, at 17:40, Björnke von Gierke wrote:
> Did you try to experiment with lock and unlock screen too? because you can
> salvage a lot of things with arcane divinations (aka. randomly adding lock
> screen at improbable locations and look what it does, which will be somewhat
> random, sometimes slowing stuff down to a crawl, sometimes solving all
> problems).
>
>
> On 30 May 2011, at 21:30, Todd Geist wrote:
>
>> thanks for confirming my findings :>)
>>
>> Todd
>>
>> On Mon, May 30, 2011 at 11:47 AM, Scott Rossi <sc...@tactilemedia.com>wrote:
>>
>>> In my experience, the only way to get smooth (ish) resizing of a stack is
>>> to
>>> use the built-in resizer and set the liveResizing of the stack to true.
>>> Scaling by script is never as fast, and as you've seen, you will often see
>>> controls update along with the blank (white) background of stack as you
>>> drag-resize. Unfortunately, using the default resizer this means you are
>>> stuck with the standard window decorations.
>>>
>>> A compromise/workaround can be to limit your app's resizing to specific set
>>> sizes. By having a button or similar that expands/collapses the stack
>>> between fixed sizes, you can remove the window decorations and avoid the
>>> slow resize problem, at the cost of no manual resize.
>>>
>>> Regards,
>>>
>>> Scott Rossi
>>> Creative Director
>>> Tactile Media, UX Design
>>>
>>>
>>>
>>> Recently, Todd Geist wrote:
>>>
>>>> I have tried all of the suggestions in this thread, and while they all
>>> work,
>>>> they all cause a little stutter with my geometry. Specifically I have a
>>>> group "Nav Bar" at the top of the card. This group resizes on
>>> resizeStack
>>>> to fill the screen left to right. No matter what I do that group resize
>>>> doesn't happen fast enough. It always shows a little white gap before
>>>> resizeing.
>>>>
>>>> When I use the built in resizer, my group NavBar resizes perfectly.
>>>>
>>>> I really just want to get rid off all the window chrome EXCEPT the
>>> resizer.
>>>> But that doesn't seem possible
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>
>>
>> Todd Geist
>> ------------------------------
>> geist interactive <http://www.geistinteractive.com>
>> 805-419-9382
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
