[V8i C++] How a DGNAPPS task interacts with FileOpen after FIle->Close

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

Parents
  • 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.

  • Generally spoken, the missing initialisation, is the the main thing I expected. I never used MS_INITAPPS, but from the last xx years reading here, I got a thought. I rely on a file and model being loaded for my app, even the GUI has to be loaded. So I still have to test for a MS_DGNAPP, if the model is finally loaded. Missing tcb->values etc. are some possible sources of errors, that's why I said it 'might' have disadvantages. I make even use of some other fancy stuff like loading analyze.ma to get translated element names, use of MFC, don't know what might be missing at the time, before even the first file dialog exists.
    Said so, I have some good knowledge of the possibilities of the SYSTEM_NEW_DESIGN_FILE callback, and how to make sure files are treated at closing and make some init after they are finally opened, so I might be of help there, but for the other side, there need to be people like you, telling the pro's and con's (or do's and don't's) of MS_INITAPPS.

    Regards, Michael



  • > 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.

     

    Cheers,

    /Chris Z.

  • cool, and with a callback that reacts on SYSTEM_NEWFILE_COMPLETE the above might be solved by changing the app's class, preventing it from unload, and asuring the model loaded completely after the file dialog was confirmed.



Reply Children
No Data