[TD 6.0 RTM] Problem with SalDlgSetDockSlide

[lrcuand]

Hello,

I use the function SalDlgSetDockSlide to slide the docked dialog window out. But after that call, the user can't slide in the docking window with a mousclick.

SlideMenu.jpg

SlideMenu.zip

[Jeff Luther]

Not sure what you are trying to do, Kurt. I back-converted a copy to v5.2 and it and v6 behave the same: I cannot do anything with that "Menu" item left side of the MDI window. You wrote that you use the function "...to slide the docked dialog window out", but when? What version of TD? Neither v5.2 (I'll attach a copy) nor your test in v6 do anything when I click/slide on "Menu."

[lrcuand]

I cannot do anything with that "Menu" item left side of the MDI window.

Exactly that is the problem! Why it isn't shown, when you click the "menu-slide"
Apparently the same problem is in TD 5.2.

[Jean-Marc Gemperle]

Hi

This is what the HLP says on the function and on its behavior

bOk = SalDlgSetDockSlide(hWndDockingDlg, bSlide)
Slides a docked window in/out. This function has the same effect as manually clicking the "pin" (AutoHide) button of a docked dialog window. Once TD calls this function to slide a docked window, the native "AutoHide" feature will stop working in order to avoid a conflict between the Sal function and native "AutoHide" feature.

IMO this is consistent with the behavior we see. Basically once you use that function the user cannot any longer pin/un-pin (auto-hide) the Dock Dlg as explained in the HLP. What does work is to have for example 2 pushbuttons on the toolbar one that slide in and out and this is working fine. So IMO this is the way the function was designed... indeed wonder what could be the context for this function to be used then as you cannot trap docked dialog box message to achieve the same as what a user would do...

Now I understand you like to INITIALIZE your dock windows at runtime in a certain way, actually SalWindowApplyDockState/SalWindowWriteDockState would allow you to do in some way the same see attached.

To be completed SalDlgSetDockSlide() currently does not work when targeting for WPF => TD-14402

Jean-Marc

[Nils Jänicke]

So using this function the user cannot use the dockable window as expected. So it is a bug, I think, because it is not possible to initialize the slide state and use the docking window.
So please do something to give us the possibility to use this feature:

- New function SalDockSetAutoSlide(bOn) to switch on/off the normal behavior
- Some SAM-Messages to query if the mouse button is over the zone normally sliding the window and a message sent on clicking the pin to slide out

Nils

[Jean-Marc Gemperle]

Well according to the Online help this is not a bug but as designed and DOCUMENTED so with all due respect I disagree this time with you... I don't argue here that I wonder the context of usage of this function though... Also as I mentioned using SalWindowApplyDockState/SalWindowWriteDockState you can achieve the SAME...

This say I perfectly understand you like to use that functionality without the documented limitation so here it is TD-14403

Jean-marc

[Steve Leighton]

.
As an addendum to using SalWindowApplyDockState() - which can really flicker as the Dialog is being re-set to its Saved state,
I found that suspending painting of the Parent ( MDI ) can make everything alot smoother.
I know its not the answer for every situation - but its worth a try if you get the screen shakes :
p.s. you may need to suspend painting on the actual dialogs being re-docked also, to make things even more smooth.
p.p.s. Dont forget to re-enable painting as soon as SalWindowApplyDockState() is done - which in turn re-paints the finished result.

SalWindowApplyDockStatePainting.JPG