Hi folks,
I just discovered the joys of using the DIALOGATTRX_NETDOCKABLE attribute. I now have a dialog that is nicely pinnable on the side of the MicroStation window where it doesn't hog screen real-estate. There are only two problems that enabling this attribute causes in my application:
I can't find a workaround to these problems, and needless to say, they are show-stoppers for me using .NET docking. If I turn off this attribute in the resource file so I have normal window docking, then these problems both go away, but I lose the advantage of pinnable docking. Has anyone seen either of these problems before? Problem #2 is the big one. I've tried calling mdlWindow_organizeApplicationArea() to no avail, but I suspect this function is not .NET docking-aware.
Cheers.
Piers, could you please write versions of used MicroStation and used Windows?
I am using .NET dockable windows in my native apps, but I had to make also a .NET helper library to manage similar issues. As far as I can say, helper is needed if you want to use .NET dockable windows in XM and in first V8i release.
I suggest you to create a .NET addin that will handle your native dialogs. It sounds bad, but it works :)
Sorry Dan, should have specified: v8.11.09.459 (the latest SS3).
This is not an in-house application, so it needs to run on all MicroStation versions, though obviously these bugs only affect V8i. I'm currently testing on Windows 7, but will eventually test it on every Windows platform. I have been loath to use .NET addins as my first attempt at running an addin kept hosing the MicroStation install in unrecoverable ways. I also found development was extremely tedious due to the need to continually restart MicroStation due to the absence of an equivalent to "MDL UNLOAD".
Unknown said: I also found development was extremely tedious due to the need to continually restart MicroStation due to the absence of an equivalent to "MDL UNLOAD"
That problem has been discussed a long time ago. I don't have the solution to hand, but it's something to do with running your apps. in a dedicated .NET namespace, which can then be loaded/unloaded independently of the rest of the .NET runtime.
Search the archived V8i programming forum.
Regards, Jon Summers LA Solutions
Thanks Jon, I'll check it out. It was unresolved when I first reported it, I guess I should have kept up.
The good news is that I have now resolved problem #2. It seems I made a mistake in reporting that the glitch still happened when I set NOHOOK for the dialog, as now I can't seem to replicate it with NOHOOK. Further investigation revealed that the cause of the problem was that my custom hook calls mdlSystem_pumpMessages(). It needed to do this because I was rendering the cells to a local cache image prior to display, and large cell libraries may cause the system to appear to "hang" if this is not called.
So while I now have two work-arounds for these problems, it seems there are a couple of bugs/caveats to watch out for (or Bentley to fix). To summarise:
Hope someone else finds this useful.
Cheers!
Answer Verified By: Piers
Unknown said:it's something to do with running your apps. in a dedicated .NET namespace, which can then be loaded/unloaded independently of the rest of the .NET runtime
Just to correct this, addin must be loaded in its own AppDomain (there is some special tool for this), but then you can not use MicroStation docking system (at least for me it was crashing due to unresolved crossing AppDomain boundaries - not as easy to share data between two addins, they needs to be loaded into one AppDomain and so on). Each AppDomain is something like separate process, so it needs special handling and it also always loads complete .Net Framework to RAM. It is good for testing, however.
Unknown said:A docked dialog may not call mdlSystem_pumpMessages() from the resize hook, or it will leave the docking handles permanently on-screen.
I think that you should never call mdlSystem_pumpMessages in UI hook - especially not resize.Or you should use a timer tick hook.
Instead, use:
MSG msg;while (PeekMessage(&msg, hwnd, 0, 0, 0)){ TranslateMessage(&msg); DispatchMessage(&msg);}
where hwnd is a handle to control/window you need to have responsive. You could also set wRemoveMsg parameter of PeekMessage to PM_QS_INPUT | PM_QS_PAINT for handling only input and paint messages.Note, that it must not be a hook corresponding to hwnd.