Prev: Overlapping file IO (access denied) on Windows 7
Next: XDrawImageString
From: dgwin32 on 27 Jun 2010 02:38
> I assume your custom controls allow this type of construct. . . .
>
> HWND control;
> control = CreateMyCustomControl(arg. . . .);

They do, but... my main application loads dlls in a type of plugin
and way so the main app wouldnt have handles to them. For example
I would create a DLL called "colourpicker" which would have
functions to create a toolbar and a colour picker button, etc. The main
app would just been looking for this dll and load it, and look for common
functions to run it such as start_plugin(), end_plugin() etc. It would call
the
start function which would setup the pluggin app, etc. It woudln't pass
handles
back to the main app since they could pretty much be doing anything.


From: winapi on 27 Jun 2010 12:57
>> I assume your custom controls allow this type of construct. . . .
>>
>> HWND control;
>> control = CreateMyCustomControl(arg. . . .);
>
> They do, but... my main application loads dlls in a type of plugin
> and way so the main app wouldnt have handles to them. For example
> I would create a DLL called "colourpicker" which would have
> functions to create a toolbar and a colour picker button, etc. The main
> app would just been looking for this dll and load it, and look for common
> functions to run it such as start_plugin(), end_plugin() etc. It would
> call the
> start function which would setup the pluggin app, etc. It woudln't pass
> handles
> back to the main app since they could pretty much be doing anything.


How does your color picker tool(after the button is pressed to display it)
know where it should be moved in relation to it's parent? How have you
handled
the required messages you would need. In other words the communication
between
your color picker pop up window, and it movement ralative to a "desired"
window?


From: dgwin32 on 28 Jun 2010 03:01
Well, I intially tried to use the GetParent on the hwnd passed to
the colourpallete popup window but it points to the main mdi frame
not the colourpicker button, because I wanted to display it bottom left
of this. I ended up saving the parent handle passed in the WM_CREATE
which is the colourpicker button.

I tried putting my movewindow code in the WM_WINDOWPOSCHANGING
event but obviously the window hasn't actually moved so when i calculate
my new movewindow point its in the previous place.

I can't detect a useful event 'move' in the popup callback to be able to
move it
correctly. If i could detect the WM_WINDOWPOSCHANGED (for the main window)
in my popup callback I think it would work how I want it to.


From: winapi on 28 Jun 2010 13:44
> I can't detect a useful event 'move' in the popup callback to be able to
> move it
> correctly. If i could detect the WM_WINDOWPOSCHANGED (for the main
> window)
> in my popup callback I think it would work how I want it to.
>
>

I modified this MDI to see if I could get something working. Seems to work
ok.
But this example is very basic. Maybe this might be of some help?

http://rapidshare.com/files/403599554/MDI.zip.html


From: dgwin32 on 28 Jun 2010 18:24
Thanks for that. However, I've found another solution,
I'm not sure if you are supposed to do it this way or not
but it works for me..

In the main application code I registered a message
and send it to all the toplevel windows using the broadcast handle.

e.g

init()
{
uMdiMovedMsg = RegisterWindowMessage ("my_mdi_moved_msg");
}

mdiWndProc()
{

switch(msg)
{
case WM_WINDOWPOSCHANGED:
SendMessage (HWND_BROADCAST, uMdiMovedMsg, 0, 0);
break;
}

....
}


palettePopupWndProc()
{
switch (msg)
{
case WM_PAINT
... whatever.
break;

default:
{
if (msg == uMdiMovedMsg)
{
MoveWindow (hwnd, ptx, pty, width, height, TRUE);
}
}
return (DefWindowProc....);
}

}

Hope that make sense. It seems to work, the only thing i'm not able
to do is clip the popup with the MDI frame if you resize an egde to overlap
it.



First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Overlapping file IO (access denied) on Windows 7
Next: XDrawImageString