AutoHotkey Community

Very nice. Its not that much of a hack though, you will have to cover entire tab control in any case.

So, you used 2 T clients - one for "SteamLab" tab and other one is added/removed when you click on the first one (notice that you must remove it starting from b3, not just hidden), right ? you can generaly use only 1, if you just update its dock definition when it is clicked. Initialy, it shows only tab and the rest of the window is just not visible as it falls outside of visible client area. When its clicked, you just update the dock definition, specifying new size. When overlay infront of other Steam tabs is clicked, you can return initial Dock definition and show only tab again. I guess it could work OK as alternative solution...

This will have to be done even with officialy introduced docking relative to the controll, as there is no way for dock to recognise when Tab is clicked (its out of domain of its task). The only and important difference would be that Dock would calculate the size of the client for you, based on controls size, and you have to do it manuely now.

Hm... thinking more about it, standard Tab control doesn't include so called Tab Pages, they are controles per se in most languages. So, maybe, dock will be even able to recognise tab switch and consider new tab as new control That way, you can simply dock to the adequate tab page to replace it, or update it. If you want new tab, you will have to use the old principle anyway.

_________________

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...

He he, I maybe paniced without reason. I maybe fixed the Host resizing so now it works fluidly
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...

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

My Trac projects
My Wiki
[Broken] - My music

I really don't know... I thought I have it , but I am not so sure now... I can improve it a bit...

You should try with Dock 2.0 a5 also. You may notice better behavior.

I will play some more in upcoming days and then I will see what version to choose to continue work on, or I will try to merge them...


This is OK.

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

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

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 ....

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.


Please add this at the end of the Dock_hookproc:


So just comment DOck_Update and call it in timer. Experiment with period. -10 works fine here, but more then -20 will not be fluid.

_________________

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....

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

My Trac projects
My Wiki
[Broken] - My music

I never experienced such behavior. Only:


Moving ? Here, moving works OK, but resizing is a little slow.


Be aware that dock_hookproc runs on message frequency. The fact that it usualy exits ASAP means that it can still interupt important processing, like that of Anchor wich is also run on message frequency, pretty much on same event. Perhaps some priroity could be set for Anchor.

This can have unexpected problems. Toggling dock off can help, and toggling it on after the task.

For instance, I moded 2.0 a5 version to support "jumping hosts". The same client is not tied to single Dock_HostID but Dock asks for ID function that returns 1 if currently proccesed HWND by the Dock (that on wich some action is going on in the system) is to be docked, 0 if not, and -1 if clients are to be turned off. I use this in Favmenu to put title button on dialogs it operates on (TC, Explorer, Open/Save, BFF, Console) and to hide the button when none of them is active. It works great, title btn is jumping very nice, moving is smooth.
However I noticed that when I click the button some parts of the Favmenu don't work as expected. So, I did something like

to fix it, and from that moment it worked. I didn't analyze troughly that behavior, perhaps some trivial bug is in question, but I expect that something like that may be the case with Anchor.

In any way, I will need a little time to sort my thoughts out about this, and see what is the best possible way to continue or finish this.

_________________

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:


P.P.E. Doh!!! I had it all right! I just had to remove the string and uncomment my first line to sSaveasName = "Untitled - Notepad" ;Save As. Thanks for listening you guys.

P.S. You've got one too many [/list] tags in your original post.

P.P.S. "P.P.E." means Pre-Post-Edit and "P.P.S." means Post-Post-Script"

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

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.

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!

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.

_________________

THX A lot!
It works perfect!
Greets,
DHMH