AutoHotkey Community

majkinetor · Joined: 24 May 2006 Posts: 3626 Location: Belgrade

BTW, I will maybe revert to latest a version, a5.....

It turns out that owned windows are NOT better then previous implementation (they make host resize much slower, but work are slightly more reliable; moving works equaly fast as before).

I don't know yet....

For instance, setting 20 caption buttons makes host resize really slow comparing to version a5 wich works pretty good although what it does is more intensive then in version b3 where most of the things are left to the OS to handle.

Please, if you can, test this. Only T clients are affected. This is important decision.

Maybe I can unite both versions and add new flag, like T1 to use previous implementation and just T to use this one, although this will complicate things for me...
I am tending to leave current solution as if topmost window is dropped for some reason, in previous implementation, it will stay on top everything while that can never happen with latest T code (as OS is handling that).

So there are positive aspects of both implementations, and negative. Its just matter of how many T clients will be usualy used, I guess....

There is also a moment where previous T implementation wasn't semanticaly correct - T clients shouldn't be topmost windows in entire system but just relative to its Host. That was producing quirks with other topmost windows in the system sometimes...

Damn.. who would say.. doesn't seem like much of a code, but its terribly complicated.

No wonder I never saw before something like this, except in PowerPro wich cant be compared to the complexity of the Dock with little time I tried it...

majkinetor · Joined: 24 May 2006 Posts: 3626 Location: Belgrade

He he, I maybe paniced without reason. I maybe fixed the Host resizing so now it works fluidly Very Happy

He he...

Damn... its 14 and I have dead line at 17, or entire law system in the country will not receive salaries..... damn dock... I am doomed.. :?

But, lets go to pause first. Dock exosted me... Cool

bmcclure · Joined: 24 Nov 2007 Posts: 446

Nice work! I'll test your latest posted version after work today and get back to you with the results.

Through adding some strategically placed calls to the GuiSize label, it is coming up more often than it used to as the correct size. I notice something weird, however:

1. When it actually appears correctly, you can see the ListView being drawn original size in the middle of the screen when the dock is shown, and then immediately "jumping" over into the dock at the correct size and location.

2. It usually still doesn't work. If I click the Games tab about 20 times, sometimes one or two times it will show up correctly sized. The other times it will show up as the default size.

Resizing after the dock is shown is OK. It still fails to anchor them a lot of the time, but usually when you stop resizing the controls jump to the correct size again, which is OK.

I noticed also that resizing was a bit slow with 3 t clients (I could bring this down to two as you suggested though). Perhaps that is faster in the latest release that I've yet to try?

Also, the tabs in my GUIs aren't real tab controls, but just functions that create collections of Gui pictures that use G labels and OnMessage events to simulate tabs. In my tab functions I allow the specifying of a G-label to go to when the tab is clicked. So in the label, I get the text of the tab clicked and show the appropriate dock over the main Steam window. There may be a better way of doing this, since it has less than one day of testing under its belt so far. But it's working, and that rocks!

Thanks for all the hard work, Dock() is truly powerful!
_________________
-Ben

SteamLab
SteamLab Wiki

[Broken] - My industrial music [on GarageBand]

majkinetor · Joined: 24 May 2006 Posts: 3626 Location: Belgrade

majkinetor · Joined: 24 May 2006 Posts: 3626 Location: Belgrade

Some really weird behavior now.

Using the samle _Customizable Left Side.ahk i obtained this info - when clients are set T, it works much better in this case then when clients are non-T. In some other scripts T clients are slow.... I am really confused... . Nothing in the code itself is different. Same amount of code executed, everything is the same, except that in second case clients are set as owned by the Host and first they aren't.....

Ohhh Yooour Gooood Twisted Evil

On the other hand, previous solution, non owned topmost clients work better then T clients now, which is even more absurd as this is definitely the most expensive solution ...

Ohhh Yooour Gooood Twisted Evil

HM.... it might be this - Windows OS is reserving more CPU time for active application. It seems that it considers as active even the window that is set as owned by the Host, although its not part of that process .... It seems that client dimensions don't influence this much, but it goes worst when clients are larger and non - T. To see this, just add T in mentioned script and move Notepad around like crazy (set 5 clients). You will notice much more fluid movement with T. If you play with client size and possition it wil become apperent....

I will go insane ....

majkinetor · Joined: 24 May 2006 Posts: 3626 Location: Belgrade

Well, it seems that dock behavior depends on Host's complexity. Notepad works much better then Total Commander, with the same dock, the same code.

I guess this is as fast as AHK as interpretative language can go. So I guess we can not exagerate whit number of dock clients.

majkinetor · Joined: 24 May 2006 Posts: 3626 Location: Belgrade

Version a5 works the best so far, IMO.

Here, moving the windows around while they are OWNED, makes the dock very slow. As soon as you make them non-owned, dock starts to shine again....

This is with title buttons... depends somewhat on script, who knows why.

If nothing else works on this problem, I will revert to old T implementation....

bmcclure · Joined: 24 Nov 2007 Posts: 446

b3 seems to work alright. I have some unexpected bugs though, I think.

For one, my docks are drawn in the middle, not the correct size, and they wait several seconds, or until I move the host window, then they jump to the correct location.

Where it would normally draw my SteamDock immediately followed by the SteamTabs, this is what happens:

1. Steam window is shown
2. SteamDock appears in middle of screen, wrong size
3. 3-4 seconds later, SteamDock jumps to right place and SteamTabs appear in center
4. 3-4 seconds later, SteamTabs jump to right place

Moving is a little slow for a moment usually, then the speed isn't bad and the docks move pretty smoothly.

Another weird bug. The actual Gui elements in my window are not drawn in the right place with this version, but they snap to the right place (and are anchored correctly) after a few seconds.

-------------

And while I was typing all that, my dock froze, which also apparently made Steam freeze, as well as Firefox (the active window). I could not end any of them in the Task Manager. I logged off and back on, and the processes were still running. I ended up having to hard-restart my computer. I think there may be something going on with b3
_________________
-Ben

SteamLab
SteamLab Wiki

[Broken] - My industrial music [on GarageBand]

majkinetor · Joined: 24 May 2006 Posts: 3626 Location: Belgrade

I never experienced such behavior. Only:

Murp|e · Joined: 12 Jan 2007 Posts: 240 Location: Norway

I'm trying to dock a custom GUI to a Save As dialog belonging to another application, but instead of docking to the Save As window my GUI is docked to the main notepad window.

I also need to validate that the calling/parent window of the Save As dialog, since I only want to dock to Save As dialogs called from a certain application.

I first thought it had something to do with parent/child relations and found the dllcall(getparent) command which I managed to use. I finally realised that this probably was completely wrong, since the dllcall returns the parent window of a control, not the parent window of a child window.

So I thought I could validate the calling window by checking the processname. That part works fine, but like I mentioned above instead of docking to the Save As dialog it docks to the main notepad window. This is what I've been trying:

rogal · Joined: 23 Dec 2007 Posts: 51 Location: Austin

Oops .. I have not been notified of those changes. majkinetor, you are very diligent Smile

I have downloaded 2.0 b3 and it works fine. I will let you know if something happens. FYI, Im using the dock for WinEdt.

Thanks again.

alaricljs · Joined: 06 May 2005 Posts: 15

I'm interested in using Dock to get titlebar buttons with my script, however I would need to be able to use multiple HostIDs. I'm digging into your script to see if I can do the mods myself, however if it interests you it'd be great to get your take on Dock with multiple Hosts.

Thanks
_________________
Spoon!

majkinetor · Joined: 24 May 2006 Posts: 3626 Location: Belgrade

You will have example soon. I am having 1 title button on all system dialogs (6 kind of different windows) in Favmenu 3. So far it works great and it will be there for you to check it out when i release FM3. Other then that, changing Dock on your own isn't recommended as every single command counts and if you just remove one line entire dock may mailfunction. Those lines are forged during long time and over many iterations to work perfectly the way they do now.
_________________