[gme-users] Is it possible to get the mga file from interpreters/etc. ?

[Peter Volgyesi]

Hi,

You can do (almost) all of these, however you will have to use the COM layer
(there is no support for such tricks in BON or BON2). 

> Hello all,
> if I build an interpreter, or a gme component, or something 
> like that... 
> is it possible to get the full .mga file which is currently 
> loaded? (or even the xml export version of it could be ok for me)
To get the path to the current mga file, use the following code snippet
(BON2):

CComPtr<IMgaProject> mgaProject = project->getProjectI();
CComBSTR bstr;
COMTHROW(mgaProject->get_ProjectConnStr(&bstr));
std::string connstr = Util::Copy(bstr);

- connstr will contain a connection string in the following form: "MGA=<path
to the mga file>".

To create an XML exported version of the current project (using an arbitrary
xml file):

CComPtr<IMgaProject> mgaProject = project->getProjectI();
CComBSTR bstr("XML=C:\\Temp\\project.xml");
CComPtr<IMgaDumper> dumper;
COMTHROW( dumper.CoCreateInstance(L"Mga.MgaDumper") );
ASSERT( dumper != NULL );
COMTHROW( dumper->DumpProject(mgaProject,bstr) );

- Unfortunately, you will have to modify your project settings to be able to
compile the XML based stuff.
If you really want to take this way, I'll try to help.



> And what about the other way around: if I have a mga file 
> somehow in a 
> gme component, or interpreter or whatever... can I dump it 
> into GME in 
> some way, overwriting the currently working document? (The metamodel 
> would be the same as that of the current document)
> 
> 
> I'm particularly interested in doing this with GME version 3.x.x

In GME 3.x you can't do too much while GME.exe is running, since opening a
new project in the MGA layer will definitely crash the GUI.
In GME4 we've introduced an automation interface for the GUI. IGMEOLEApp
(implemented by "GME.Application") has the following methods:
OpenProject(<connstr>) and CloseProject(). However, I am concerned whether
these methods can be used (safely) in an interpreter. I think they are not.

--
peter