How to programmatically exit visio

[dbrannick]

Hi,
we have a custom visio app that generates flowcharts by reading an input file containing shapes, x/y coordinates, sizes, etc. It works great except for the fact that visio grows quite large opening these files and generating flowchart pages. We've tried to limit the number of pages within a visio document to 25 but after processing several of these the speed of visio drops rapidly. We've decided to just create 1 page per input document as we've noticed that it runs faster. However, what my problem now is this. I've put our visio program (with vba code) into a batch script. It starts up, runs the quantity of visio diagrams and then I want to exit visio completely out of the vba code and drop back into the operating system. (in this case, it will drop to the batch script which will loop back an rerun the visio program which picks up more files to process.
My question is how to programmatically exit visio from vba. I've tried the following without luck. What am I doing wrong?
Application.ActiveWindow.Close
Application.ActiveDocument.Close
Application.Shutdown

thanks for the help.
DB

[Paul Herber]

Application.quit

[dbrannick]

Application.quit still leaves me within visio.

These are the steps:
1. batch job runs visio.
2. visio vba code reads a parm file to know what to process.
3. visio produces diagrams.
4. visio goes to my exit routine and runs the appropriate application.quit but it still leaves visio running. It didn't close visio completely. My documents are closed but visio is still running with a blank screen.
Other thoughts?

[Michael Dag]

I had this with Word, for some reason doing Application.ActiveDocument.Close twice fixed it at the time...
Don't know about Visio 

[Paul Herber]

Are you sure you aren't closing the active document first? If you do then you will find that your code stops running at the ActiveDocument.Close
How was the code activated?

[dbrannick]

looking around further, I found this code from MS. I cut and pasted the code into mine. I'm not exactly sure what it is doing but it does cancel out of visio. However, it cancels visio as though visio aborted and I get the ms screen saying visio had a problem and it needs to send an error report to ms.
looking at this code, is there a problem with this? I didn't understand why it trys to post a message.
any help is greatly appreciated.
thanks.
DB

Option Explicit
Dim WithEvents m_Visio As Visio.Application

Private Const WM_QUIT = &H12
Private Declare Function PostMessage Lib "user32" Alias "PostMessageA" _
(ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal _
lParam As Long) As Long
Private Const STR_QUITMARKER = "DoQuitNOW"

Private Sub quitVisio()
    Dim lResult As Long
    Dim hWnd As Long
   
    hWnd = ThisDocument.Application.WindowHandle32
    lResult = PostMessage(hWnd, WM_QUIT, 0, 0)
   
    '   Allow Visio to pump the message queue.
    '
    DoEvents
End Sub

Private Sub Document_BeforeDocumentClose(ByVal doc As IVDocument)
    quitVisio
End Sub

[wapperdude]

I probably shouldn't ask this,  , but do you really need to shut down Visio?  I'm probably missing something, but, it would seem that if you save and close the current document, then open a new document, continue to execute your next diagrams, save, close doc, open new doc ought to cover your processing loop without actually closing Visio and restarting each time.  Would seem to simplify the process and save time too.  Just curious.   

[dbrannick]

The problem with that is there is a memory leak in visio. opening and closing many documents causes visio to grow steadily over time. I didn't prefix the opening topic by saying I'm trying to draw around 5000 visio pages. (this is a customized flowcharting program). If I were to try an flowchart the 5k pages, after around 50 or so, the size of the active visio.exe starts to grow. Up 5 meg, down 2meg, up 5 meg, down 2 meg. So and so on. So after a while, it grows to the point where it is consuming a 'lot' of system resources and runs quite slow. I've seen visio grow to the point where via performance monitor says it is using almost 2gig memory of a 4 gig quad machine.
My thought on this process was to let it generate the 50 or so pages very quickly, shut visio down and have it immediately start back up (via a batch loop). Hence the reason for wanting to shut visio down. It was my poor man's attempt to side step the memory leak.

[wapperdude]

Ah!     Well, you actually did hint at the problem.

I have a similar memory leak problem, except, my memory ends up empty, not full!   

[Visio Guy]

It's not clear to me where the code is. Is it inside the VBA project of a document? Is this document trying to shut itself down?

Are all of your documents saved before you quit?

I tried the following:

Code Select Expand


Sub QuitMyself()

  For i = 1 To 100
    Visio.Documents.Add ("")
  Next i
 
  Visio.Application.Quit
 
End Sub


And Visio doesn't hang around in the Task Manager, but it does climb to 50MB or so before exiting.

I suspect there are many objects that are being held on to, and preventing Visio from closing properly. Make sure you've saved everything, set as many objects " = Nothing" as you can.

You might also turn off Undo while you are processing:

  Visio.Application.UndoEnabled = False

Make sure to turn it back on when you're done, though, or your next hands-on user will be disappointed when he/she presses Ctrl+Z.

[Paul Herber]

The problem with that is there is a memory leak in visio. opening and closing many documents causes visio to grow steadily over time.

I often run tests overnight, creating and saving many documents from test scripts. I've never had a problem with a memory leak (except in my own code).

[AndyW]

Is your VBA all running from the document opened event. I originally tried that, but it can't then process the quit as it is already processing an event.

[dbrannick]

Thanks to all who provided insight on what I should do. I found that closing all the objects and then executing the quit did the trick. I now have visio doing what I need it to do. thanks again.