I've got .ma/.dll that is loaded via MS_DGNAPPS. In the .ma are callbacks for SYSTEM_NEW_DESIGN_FILE and INPUT_FILEOPENDIALOG_PREPROCESS. Once a model is opened, and File->Close is picked from the menu, the current model is closed and MicroStation returns to a "blank" window with a File Open dialog. The opening of that File Open dialog is NOT being seen by my file open preprocess. Why is that? I have no SYSTEM_RELOAD_PROGRAM for the .ma, so I'm assuming (incorrectly?) that it's still loaded and active, and should be "seeing" this event. If I pick File->New from the menu bar in the dialog, it too is not "caught" by my DGNAPPS .ma.
Thanks,
Bruce
Bruce ...
File Close unloads MicroStation. it is the only way to change user/project/interface settings, thus the next opening might have a completely other configuration than the one before. Applications loaded with MS_DGNAPPS gets unloaded and will therefore not receive any event.
You can react on the closing with a callback like this :
mdlSystem_setFunction (SYSTEM_UNLOAD_PROGRAM, my_unloadFunction); which receives a single int parameter like SYSTEM_TERMINATED_SHUTDOWN or similar.
You eventually might combine this with a combination to a previously call to your SYSTEM_NEW_DESIGN_FILE call back where state is SYSTEM_NEWFILE_CLOSE. You should keep in mind that both of them are happening for a File/Close and File/Exit command, so afaik you cannot differ between them. Maybe you could react if you app was loaded an MS_INITAPPS, but this might have other disadvantages.
HTH Michael
> if you app was loaded an MS_INITAPPS, but this might have other disadvantages. Initapp basically has power to replace the File Open entirely, or spawn it at will. I am using this approach since ages ;) I would be interested in knowing more about mentioned disadvantages though. Some I ran into are that initapp is called so early in the start up process that it has to manage both initializing the GUI (aka entering graphics) and deal with the fact that parts of Tcb are basically uninitialized/invalid at that moment. Other than those I haven't seen any other adverse side effects though...
Cheers,
/Chris Z.
> people like you, telling the pro's and con's (or do's and don't's) of MS_INITAPPS.
Thanks for your kind words :)
OK, so here go some humble nuggets: the usual way to inform MicroStation about our MS_INITAPP is, as the name of the means indicates, through a configuration variable. The usual place for this variable very often is a CFG-file tossed to ...\MicroStation\config\appl where it gets read because of its bare existence there by MicroStation.
However INITAPP or DGNAPP and suchlike can be enforced at runtime by mdlSystem_setMdlAppClass, for example:
mdlSystem_setMdlAppClass ( "WHATEVER_IS_YOUR_INITAPP", APPLICATION_INITAPP );
Very handy when playing this game back and forth and changing your mind in the middle.
Unknown said:The usual way to inform MicroStation about our MS_INITAPP is, as the name of the means indicates, through a configuration variable
That's one way, but the result is that all configuration files are processed and any other MS_INITAPPS applications will also be loaded. That's given me problems when, say, ProjectWise is loaded and clobbers my MS_INITAPPS.
The way to avoid that, recommended by Barry Bentley a few years ago, is to use the -waAppName command-line switch. That loads only the MS_INITAPPS specified, so you don't get interference from other MS_INITAPPS.
The way to TCB happiness is simple: set a system callback for OnNewDesignFile, and don't do any poking around in the TCB or models until you catch that event.
Regards, Jon Summers LA Solutions