Message Blaster - too many controls
Has anyone any experience using MessageBlaster within Progress? I am using it to monitor the WM_SIZE message for a window. A user opens a case in my application and I allocate the window HWND of the case to the MessageBlaster control and it seems to detect the WM_SIZE messages fine. However if the user opens a new case a new window is created and so I allocate the HWND of that new window to the control. After I open my 32-nd case I get the messge 'too many controls'. So I am obviously not clearing out the references to the 'old' window each time I allocate a new window to the control. But I can't see a way of doing this ! I tried setting MsgBlast:hWndTarget = 0 but it objects to that. Does anyone know if there is a way ?
Openedge 10.1B Windows XP
Thanks
Alan
- Login to post comments
Re: msgblaster
1) Whats wrong with progress window-resize event ?
2) Are you explicitly deleting the control widget?
3) We use msghoo32 ocx as it has better scalability (more widgets)
Thanks for your reply 1.
Thanks for your reply
1. Doesn't work. Progress doesn't seem to recognise Codejock's floating pane as being a window.
2. No. I suppose that is something I could do - delete the control frame and reinstantiate it each time but it
would be much better if I could somehow just inform MessageBlaster than the hwnd it was dealing with is no longer valid, and here is a new one to monitor.
3. I just discovered msgh0032.ocx earlier today and was wondering whether to try it - you would recommend it? Have you have hit any snags with it? I see that it seems to be possible to set the WindowHookHwnd to 0 with this ocx - this is what doesn't seem to be possible with MessageBlaster.
Did you have any luck with Codejock Docking panes
I have been attempting to get codejocks docking panes working in a Progress V9 smart window.
Its becoming clear why they call these objects "pains".
I have managed to get the primary windows docking pane the launch and create a fresh window, then by use of the getparent() setparent() calls to user32.dll, these launched window becomes a child window in my parent window, but it seems the codejock component isnt doing any control.
I was wondering is there any trick that you discovered, to get codekock to manage panes containing seperate windows as a child within the primary window ??
(Or is there another way to do this, i.e. using dynamic frames for example?)
I have created a forum topic and attached the source code I have been experimenting with to: http://www.oehive.org/node/1125
re: Message Blaster - too many controls
I have used the MsgBlaster a lot, but never ran into the 32 controls limit. But I am not sure if we ever launched so many windows in a session.
Are you aware that you have the all the source code you need to rebuild the OCX? So perhaps you can use a debugger and see what's going wrong.
I am not opening 32 windows
I am not opening 32 windows deliberately : what I am doing is using a CodeJock control to create a floated pane and then using message blaster to intercept the resize message for the pane's container (which appears as a 'palette window'). When they dock the pane its window container disappears, but message blaster seems to retain knowledge of it, which is why I untimately hit the limit. I want to be able to tell MessageBlaster that the hwnd is no longer valid, but I can't seem to set that property to 'null' - if I use MsgBlast:hWndTarget = 0 then I get an error.
I have also knocked up a small test program which basically creates a dynamic frame and sets MessageBlaster:hWndTarget to the hwnd of the frame. I then dynamically delete the frame. If I do this 32 times then my program falls over with 'too many controls' !
MsgBlaster uses subclassing
MsgBlaster uses subclassing (the SetWindowLong function with the GWL_WNDPROC argument), and CodeJock probably does the same. When I assume that CodeJock is the first to call SetWindowLong to subclass a window and MsgBlaster is the second, then MsgBlaster must be the first to reset the subclassing: the stack of window procedures must be teared down in exactly the reversed order in which it was built. Now, I don't know much about CodeJock, but if it sets/resets the window procedure when the pane is docked, then you are in trouble. But you did not specify which error you get. I think I would try Spy++ to monitor the value of the pointer to the window procedure during the program.
The frame test is easily explained when you read the sourcecode of MesgBlaster. Well, when you dynamically delete the frame without setting hWndTarget=0. An improvement to the ActiveX code could be, that MsgBlaster checks each of its 32 entries (see if the window handle is still valid) before it throws its TOOMANYCTLS error. Right now it only counts how many entries are allocated, without testing if the allocated entries are still valid.
Thank you for that
Thank you for that explanation. I think I might look at the source code, as you suggest. One thing I don't quite understand in your message : you say 'The frame test is easily explained when you read the sourcecode of MesgBlaster. Well, when you dynamically delete the frame without setting hWndTarget=0'. I have tried setting hWndTarget=0 but I get an error. Would you expect this to work, or does it give you an error if you try it?