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 :)
Hey Piers,
I did some checking around and put this together:
In the DIALOG_MESSAGE_CREATE for your .NET Dockable dialog, you should add the following:
mdlDialog_setAutoOpen (dmP->db, TRUE);
mdlDialog_setAutoOpenKeyin (dmP->db, "mdl silentload myapp;myapp dialog open");
In the keyin, "myapp” should be replaced with the real app name, and “myapp dialog open" should be replaced with the keyin that opens the dialog.
You may also need to add the following in a OnBeforeViewsOpen system event listener:
int numOpened;
mdlDialog_autoOpen (&numOpened, RTYPE_DialogBox, TRUE);
I have not seen the #2 problem nor do I have a solution for it. If you click the title bar of the dockable dialog, the docking aids should close.
HTH,
marka
mark anderson [Bentley]
Visit me at https://communities.bentley.com/communities/other_communities/bentley_innovation/default.aspx
Hi Mark, I think your suggestion might be able to help if my application had an auto-open window, which it doesn't.
The cause of problem #1 seems to be related to the attribute: "DIALOGATTR_REQUESTBACKINGSTORE". If this is OFF, then the pinned window opens with the correct grey background colour initially. When it is ON, then the background colour is incorrectly black with my items drawn on top (which looks hideous, as shown below), but only if it was previously unpinned and docked. It's certainly not something I am doing wrong in the dialog hook, as I can set NOHOOK and still get the same problem. It seems that it is a MicroStation bug that windows docked and unpinned with backing store set are not correctly initialised with the right background window colour. If the user resizes the docked panel, it causes a refresh that fixes this, but docked windows do not respond to a programmatic resize request, so I can't program my way out of it.
I tried doing a mdlWindow_rectClear() on dialog open, but this does not succeed - possibly because the window is not shown until the user hovers over the tab to expand it. I don't really know how to hook the time when the user hovers so that I can clear the black background before rendering my items. As you can probably guess from the screenshot, my window is a cell selector, so I need to use the DIALOGATTR_REQUESTBACKINGSTORE attribute, otherwise none of my required image rendering functions work (e.g. mdlWindow_capture() - as I mentioned in another thread).
Problems #2 is also tricky, and I get this problem about 50% of the time when undocking my window. Again, disabling the dialog hook altogether makes no difference, and nor does disabling the backing store. Clicking on the title bar does redraw the dock icons momentarily, but they remain after letting go of the button and stay on top of all windows (even non-MicroStation windows) until MicroStation exits.
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
Piers,
Have you compared your code to the CelExp example to see if we can use the example to reproduce the issue?
thanks,
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.