Trying to create a slide up drawer in stack

[andyt]

I'm really struggling to achieve a simple panel that is the width of the parent stack and slides upwards 250 pixels say from the bottom of the stack on mouse hover and slides away almost fully when mouse out. It is always partially visible so that it can be called into play on a mouseover action.

This is a very common UI feature and I've tried every which way to achieve it with tabs, cards, substacks, all to no avail. There is on this forum a great example of an independent sliding stack which is detached from the main stack and is relative to the screen which isn't quite what I want. I've tried in vain to modify this to work within the main stack window.

http://forums.livecode.com/viewtopic.php?t=8206&p=39064

What is the best way to achieve this please?

[Randy Hengst]

Try this to get started. Place a graphic along the bottom of a card. Then in the graphic use this code:

on mouseEnter
move me relative 0,-100 in 60 ticks
end mouseEnter

on mouseLeave
set the top of me to the (bottom of this card - 50)
end mouseLeave

[MaxV]

If you are working on two separette stack, use the screenloc property, you can manipulate it.

[fgr33n]

If you are doing a UI in the "drawer", group all your buttons and background graphic together. Then put Randy's script on the group.

[andyt]

Well I've managed to build a sliding draw using a graphic - thanks for the tip, I didn't think of that option. BUT I've spent the last 6 hours trying to get the draw group to adapt to window resizing.

Why is this so hard? I've got a resizeStack handler that basically resizes the group as follows:

Code: Select all

set the rect of group "slideMenu" to 0, stackHeight-80, stackWidth, stackHeight+170

BUT it doesn't work reliably and on some occasions breaks the slide motion on mouseEnter after resizing the window.

Anyone got a simple demo of a graphic group that resizes with the window or any clues where I'm going wrong?

[FourthWorld]

Resizing groups can be tricky until you set the lockLoc of the group and each of its enclosed objects to true. Without that, the engine struggles to know how to place things in a context that's changing out from under it. But with lockLoc set, your script has control and leaves nothing to any automatic layout accommodations groups would otherwise provide.

[Randy Hengst]

changing the size of a group does not automatically change the relative sizes of the controls in the group. Best I know, you need to script the relative size changes for all the controls in the group.

[FourthWorld]

changing the size of a group does not automatically change the relative sizes of the controls in the group.

True, but if they're unlocked it can change their position. And if their positions are changing within an unlocked group, this may cause unintended consequences for the group's ability to accommodate such changes on the fly, esp. with regard to the group's margins and any graphic effects or other properties not commonly taken into account when scripting positions.

So the easiest way to have complete control under script of how objects behave within a group that can be resized is to set the lockLoc of the group and its interior objects. In some cases it can also help to set the backSize of the group, but from what I understand of this layout that shouldn't be needed here.

Try it, and see if it doesn't make working with dynamically resized groups a little easier and more predictable.

[andyt]

Thanks everyone for your help on this. lockLoc worked a treat FourthWorld.

I've attached an example of what I've been trying to achieve for soooo long.

sliding_drawer.zip

(2.18 KiB) Downloaded 224 times

You'll notice that the drawer will re-open almost immediately even if the mouse leaves it during it transition South. However I tried to employ similar code to make it close if the mouse leaves mid transition North. It didn't work and if your mouse leaves the drawer as it is opening then it doesn't seem to be aware that the mouse has left and should close.

The other obvious flaw (if indeed it is one) is that if you resize quick enough while the draw is open or in transition the resize handler returns the drawer abruptly to its closed state. If anyone can improve on this then please feel free. Hopefully it will be useful for others.

PS. I'm now going to try and achieve the same thing using animationEngine.

[andyt]

Okay, this isn't exactly working 100% of the time. I have successfully built a sliding draw now using animationEngine and I can create a static group and make it respond perfectly to stack resizing. The problem is when I combine the two.

After the window resizing has taken place sometimes the drawer group doesn't respond to the 'set rect' command in the resize handler or the mouse over stops working. Either can be fixed by making another resize attempt or two, or three often with the ugly effect that the drawer opens on mouse over and grows to the size set in the resize handler.

I'm using the glx framework and my code is as follows:

In the program stack:

Code: Select all

on PreOpenWindow pHasBeenOpened
   ## EQUIVALENT TO preOpenStack BUT WITH A PARAMETER LETTING YOU KNOW
   ## IF WINDOW HAS BEEN OPENED DURING THE APPLICATION SESSION.
   set the width of me to 900
   set the height of me to 600
   set the loc of me to the screenLoc
   put the width of this card into cardW
   put the height of this card into cardH
   set the rect of group "slideMenu" to 0, cardH-10, cardW, cardH+240
   set the width of graphic "slideMenuBkg" to cardW
   set the loc of graphic "slideMenuBkg" to the loc of group "slideMenu"
   set the lockLoc of group "slideMenu" to true
   set the lockLoc of graphic "slideMenuBkg" to true
   --initialize the slideMenu global to false
   put false into gExitingMenu
end PreOpenWindow

In the card script:

Code: Select all

on ResizeView pWidth, pHeight, pOldWidth, pOldHeight
   ## EQUIVALENT TO resizeStack BUT SENT WHENEVER RESIZING OF CONTROLS MIGHT
   ## BE NECESSARY SUCH AS WHEN NAVIGATING BETWEEN CARDS IN A STACK
   ## THAT IS ALREADY OPEN
   set the rect of group "slideMenu" to 0, pHeight-10, pWidth, pHeight+240
   set the width of graphic "slideMenuBkg" to the width of group "slideMenu"
end ResizeView

It is as if the resizeView handler isn't always triggering but I can't explain the mouse over breaking.

Any clues anyone?