Hi Andrew,

The error you encounter is perfectly valid, since what you're really doing is pulling 
out the rug from underneath Pro and your
application. Every time you make a connection, using DDE or COM or something else, 
Windows resources are being allocated, and
pointers are created to bind the two apps together. When you prematurely terminate one 
side of such connection, without first
closing all connection links, Windows is left with a lot of dangling pointers, and 
these a prone to create all kinds of havoc. A
gross protection fault error is probably the best result you can hope for.

It doesn't matter which side throws the error, it's the live connection that's being 
severed.

But the situation you describe is somewhat un-normal. Normally you'd use COM (or DDE) 
in one of two cases:
1. with Pro completely hidden, i.e. created. Here your app terminates Pro, and knows 
when to close the connections.
2. connecting to a running instance, a visible Pro. Here you'd most likely have a 
simple MapBasic app to interface between the EXE
and Pro.

In situation 2, I would suggest having an EndHandler in the MBX, that when called 
takes care of comminicating some kind of terminate
signal to the EXE, so the connection can be closed properly prior to Pro being closed. 
That should take care of the gross errors.

I've used this method several times, and it works for me. It may possibly also be 
achieved with callbacks, but I find the method I
just described easier to work with.

Best regards/Med venlig hilsen
Lars V. Nielsen
GisPro, Denmark
http://www.gispro.dk/
----- Original Message ----- 
From: "Canfield, Andrew" <[EMAIL PROTECTED]>
To: "Mapinfo-L" <[EMAIL PROTECTED]>
Sent: Thursday, May 20, 2004 9:25 PM
Subject: MI-L MapInfo Automation


> I have a question for anyone who has done Automating of MapInfo via raw COM
> or Ole. When you create an instance or connect to an instance of an
> automatable application on Windows you can use any one of a dozen languages
> to do it. I have tried this in everything from C++ to Java to VB today and
> it's always the same.
>
> Mapinfo versions 6.0, and 6.5 tested so far today. Here is the problem: You
> connect to a running session of MapInfo. If the user gets a hold of MapInfo
> and closes it while you are connected to it MapInfo throws a really gross
> error not my app but MapInfo itself. Why is this????
>
> No other application when being connected to does this? I have tried Word,
> Excel, AutoCAD, OutLook, and a few more. If you are connected to them and
> they shut down while you are connected nothing happens.
>
> What is up with MapInfo doing this? Anyone know? I am going to test it on
> MapInfo 7.0 when I go home from work today as we don't have 7.0 here at
> work.
>
> The easiest way to see what I am talking about is do the following in any
> Office product that has VBA. I did the example in Excel:
> Open Excel hit Alt+F11 to open VBA
> Right click on the Project and Insert a UserForm
> Put a button on the form right click and go into View Code
>
> enter this ( and make sure you have Mapinfo running ):
> Option Explicit
> Dim oMap As Object
>
> Private Sub CommandButton1_Click()
> Set oMap = GetObject(, "Mapinfo.Application")
> oMap.Visible = True
> End Sub
>
> Run it. Now you are still connected to MapInfo because you have set oMap =
> Nothing. Now close MapInfo and witness the error. I have done this today in
> everything from Raw COM in C to Ole in C++ and no matter what it still
> happens. Any ideas? Is this a known bug? Any help would be appreciated.
> Thanks,
> Andy
>
> ---------------------------------------------------------------------
> List hosting provided by Directions Magazine | www.directionsmag.com |
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> Message number: 11864
>
>


---------------------------------------------------------------------
List hosting provided by Directions Magazine | www.directionsmag.com |
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Message number: 11865

Reply via email to