Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
OLE Dispach Error when calling a MapInfo .MBX
Message
De
30/03/2006 07:05:47
 
 
À
Tous
Information générale
Forum:
Visual FoxPro
Catégorie:
COM/DCOM et OLE Automation
Titre:
OLE Dispach Error when calling a MapInfo .MBX
Versions des environnements
Visual FoxPro:
VFP 7 SP1
OS:
Windows XP
Database:
Visual FoxPro
Divers
Thread ID:
01109099
Message ID:
01109099
Vues:
156
Hi

My main program invokes a MapInfo (MI) application (.MBX) while still remaining open in the background, so to speak.

Just before calling the MBX, a form asks the user if he wishes to synchronise the shared tables between the two systems.

The MI uses data manipulated by the VFP app, and vice versa. But MI only recognises dBASE .dbfs (exported as FoxPlus). So the "intermediary" synch form allows update to the MI versions of the tables.

In VFP mode, I ran the main prog, called the MBX and the modal update form went through and (supposedly) updated the table(s), then was dismissed. Then I immediately got the error:
Error 1429 OLE Dispatch exception: Code 0, from wshShell.Run: unable to wait for process
The offending code is below:
If VERSION( 2) = 0	                  && If .EXE
    lcMBXLoc = ["] + JUSTPATH( _VFP.ServerName) + "\mPLANMap.mbx" + ["]
Else                                && from VFP - dev.
    lcMBXLoc = SYS(5) + SYS(2003) + "\mPLANMap.mbx"
Endif 

Do form mapUpdateGISDlog            && Query & do Copy over latest dbfs to \MapData reception dbf.

oShell       = CreateObject( "WScript.Shell")
oShell.Run( ( lcMBXLoc), 1, .T.)    && Invoke MI MapBasic application (.mbx)<<<<<<<<<<<<<< OFFENDING LINE
Meanwhile the MBX IS invoked, can be seen flashing on the task bar, and can be accessed. So the exception isn't fatal. My error handling allows me to carry on and normal service is resumed.

I assume this is something to do with task/process/job synchronisation.

Now I may have solved my own problem cos, after writing the above, I checked in the update form. As it manually has to open the .dbf tables, only if the user elects to update, i.e. not in the DE, I'd used a Close Tables All after the open-update sequence. I'd assumed this would also take care of the VFP versions of the tables, auto-opened in the DE.

I changed the DE's AutoCloseTables to .T. and since running the same sequence again I didn't get the above error.

So I'm continuing with this query because a) I've taken all the trouble to write this, b) in case that's not the problem and I may still get this in the .exe, and c) For general edification :-)

Any ideas/advice/info besides this?

'ppreciate it

Terry
- Whoever said that women are the weaker sex never tried to wrest the bedclothes off one in the middle of the night
- Worry is the interest you pay, in advance, for a loan that you may never need to take out.
Répondre
Fil
Voir

Click here to load this message in the networking platform