Comments by Okuma.Scott

Okuma.Scott 1-Oct-14 16:45pm View

And how do you do that?

Okuma.Scott 24-Jan-14 9:40am View

Thanks for your help, you inspired me to try other test windows and helped steer my sails back into the wind.

Oh and I tried adding SWP_NOSENDCHANGING but that prevents the windows from moving at all!

Okuma.Scott 24-Jan-14 7:32am View

How many windows are you moving and what type of window?

I changed my hWndInsertAfter to IntPtr.zero and took out noredraw, and performance has gone down. It takes about 2 seconds longer to execute a the move for 4 windows. I couldn't hardly believe that it works so great for you so I tried using notepad windows to test with... Bingo. The same operation with 4 notepad windows takes .6 seconds.

The test app I was using was a WPF application that has some bouncy animation going on as well as a read-out of the time including milliseconds, oh and a gradient background.

This seems to be the REAL issue and not the code.

Okuma.Scott 23-Jan-14 15:35pm View

You are correct about my surveilWidget method.
I've modified my DeferWindowPos call to this:

MultiWindowInitialStructure = Native_Methods.DeferWindowPos(
MultiWindowInitialStructure, tmp.WidgetHandle, HWND.NOTOPMOST, tempX, tmp.WidgetRectTop, tmp.WidgetWidth, tmp.WidgetHeight, SWP.NOREDRAW | SWP.NOZORDER | SWP.NOACTIVATE | SWP.NOSIZE);

Lo and behold it IS faster! But it still takes 8.7 seconds and looks pretty bad. I'm currently working on a time-dependent moving function that will vary the move amount. that combined with this might give me something acceptable, even if it flickers. Combining that with a message to freeze the window refresh might provide a workable solution. I'll let you know, but PLEASE give advice if you've done this before or know a better way! Thanks!

Okuma.Scott 23-Jan-14 13:25pm View

There is no discernible difference when using NOZORDER or NOOWNERZORDER.

Okuma.Scott 23-Jan-14 13:14pm View

You are correct about tiling.
Thank you for taking the time to read my question and the information you've provided!

Okuma.Scott 23-Jan-14 12:34pm View

1: The external apps are any executable program. For example, notepad.exe.

2: I am doing prototyping with both Winforms and WPF. attaching these external processes to parents works in both contexts but each has different flaws, which is why I am trying to do it externally using the WinAPI (which can be done easily using either context). Also the primary language I'm using is C# as you can see from the snippet.

3: No. The main problem I'm trying to solve now is this scenario: the user has 4 widgets open, and they decide to close the first one (index 0, on the left side). Now the remaining widgets need to collapse to fill the space that has opened ie. they all need to move to the left the number of pixels that has opened up. I have the logic worked out, its actually MOVING the windows that is not working as expected.

4: Not yet, although I have thought about it. "Freezing" the content of the moving windows would be acceptable but I have yet to implement the necessary messages. Therefore I don't know how it would effect the performance.

5: Refer to scenario in point 3. This is something which will come later, after I have a solution to this problem. Eventually I will need to catch move messages from title bars.

6: Refer to point 4: no, but it will be a requirement.

Okuma.Scott 23-Jan-14 11:57am View

The windows are processes that I have started, and they aren't owned by the application.
Their content is whatever developers for the platform can dream up.

Comments by Okuma.Scott (Top 8 by date)