Sounds strange, but I'm having a lot of trouble writing to text files from a VB6 add-in. This is with MapPoint 2006, although I've also tried MP2004.

The problem is occasional, but sufficiently common that if I'm writing a hundred lines of text then it will occur in either the first 'run' of my add-in or a re-run.

MapPoint 2006 itself appears to give the problem, and I get the XP message about reporting information to Microsoft. I've tried trapping errors in my file writing code - no luck.

I've tried commenting a lot of the code out so that only an open# and close# occur - still have the crashes!
(commenting ALL the file code fixes the problem, as does exporting to Excel)

I was initially using the "old school Basic" open# and close#, but also tried the modern FileSystemObject/TextStream api. This also gave the same problem.

Thinking back, I think this might be the only VB6 addin that I've written for MapPoint that writes to a text file! All the others usually write to Access or Excel via their COM interfaces.
So I checked the help file incase I missed something - a known restriction (like the non-modal dialog boxes). Can't see anything. Searches on Google and these forums also come up blank.

Is it really the case that writing to a text file in VB6 in a MapPoint addin is unreliable?

I guess a workaround would be write a C++ COM program that did the file writing and call this in a similar way as Excel.

Or I could just drop the text file output options from this add-in...

Richard

Hi Richard,

I did never write an add-in. But it's just a DLL called yes ? Maybe you can try to see if you have same problem if called from another program you write. Also then you can step trought te code.

Hope this make sence because so sayd I never wrote an add in...

It sound very strange to me there should be something wrong with writing to disk. What is the error you get ? Can you trap it ?

I get the standard XP "MapPoint has a problem" error with options to pass to the info to Microsoft.

I tried running it in the debugger, but then it works of course!


Richard

It looks like the route finding is important.

Ie. writing files & route finding.
Disable the route finding, and it runs okay.

I'd already tried "open,write,close" in one short sequence rather than keeping the file(s) open for a long period, so it isn't the fact that the file is open when a route is calculated.

Richard

Sounds like it could well be a filehandle allocation problem.
A lot of old COM code used constants when allocating filehandles. You might try assigning filehandles using freefile() and then adding 100 or something similar.

HTH
Paul

Richard, are you sure it has nothing to do with a global variable ? Do you have all local (stack) ? I have no idea, but just write what comes trough my one braincell

I've been using freefile.
Freefile+100? I could try it.

If this worked, it would mean that MapPoint (running under XP only) has hard-coded file handle?

A potential customer has a log from MapPoint, and it looks like an internal buffer overflow. Really strange!

Wilfried: I know you're guessing, but I've had similar thoughts elsewhere. This is VB6 so there are a lot of globals (VB6's concept of object oriented programming is not qute 'fully formed'). However I've been converting them to Private (yes I was sloppy with lots of public vars). No luck so far.


Richard

Just an update before I forget (again!) - the Freefile+100 didn't work.
I'm pulling the text file functionality out...

I don't like doing this, but to make up, I'm also adding support for Excel 2007's extra-large spreadsheets.

Richard