[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

  • 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

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



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

  • 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



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

  • Could you provide your function prototype and let us know if you the function is getting called at all by: e.g. via breakpoint in the function, and/or by validating by printing out each fopenParamsP->dialogId received?



  • 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



  • Unknown said:
    In the .ma are callbacks for SYSTEM_NEW_DESIGN_FILE...

    Does your MDL app. catch that event?

     
    Regards, Jon Summers
    LA Solutions