Conference abbott::teamlinks_windows

I'll ask Al Poon to look at this.  I don't think we use macros
in our Excel 95 integration, it's just VBA.  That name "bomb"
sounds suspicious.

Bob

Hi Tom,

I tried the macro commands and was able to get it to crash.  I 
don't see how the Word integration can call the crash.  If you
just the .Close or the .Quit command by itself, the function
completes with no problem.  

These commands call for closing the workbook 1 and quitting Excel.
I can't figure out why the customer wants to close WorkBook(1) before
quitting.  Workbooks(1) can be itself or any other opened WorkBook.
Can they just issue the "Application.Quit" instead?  This will prompt
them for saving modified workbooks before quitting.

Alfred///

    Hi Alfred,  
    The customer responed back with the information below. He stated he
    needed to execute both lines (in the marcro).     
    >The macro doesn't fail unless you execute both lines (i.e. a macro with
    >1 line without the other works OK). Unfortunately, I need to do both. The
    >macro is actually part of a more complex workbook. This function needs to
    >close the workbook without saving changes, and then exit out of Excel. I 
    >don't know any other way to achieve this without executing the macro 
    >commands I sent you.
    
    >Since this only fails when the TeamLinks integration is loaded, I
    >thought maybe there was a subroutine in the TeamLinks integration that 
    >might have to be called to exit from Excel instead of Application.Quit.
    
    >Users here are starting to get a anxious for a fix. If you can provide
    >a reasonable workaround, I would appreciate it.
    
    Thanks 
    
    Tommy Williams
      

Hi Tommy,

If the customer must perform a close workbook operation followed by
exit from Excel, there is another way to code the macros so it
won't crash.  I have tried it and it worked for me.

The logic is to set the .Saved property of the Workbook to True 
instead of Closing the Workbook without saving.  Once the Saved 
property is set to True, the .Quit method will not prompt the
users to save the workbook.

So have the customer try the following macro statements:

    Sub bomb()
            Workbooks(1).Saved = True
            Application.Quit
    End Sub

As for why the "Close" method causes Excel to crash in VBA32.DLL,
I don't have a clear idea.  Since VBA32.DLL is part of Excel and 
not the integration, I have no idea why it behave that way.  The
TeamLinks integration does not make calls to VBA32.DLL directly.

At this point, just propose the workaround to the customer to see
if this is a viable alternative.

Thanks,
Alfred///

    Alfred,
    
    I appreciate your diligence work for this customer. The customer tried
    the suggested work around and below is the mail message I received from
    him.
    
    Tommy,
    
    I tried your workaround. Although it worked using the simple macro, in
    my
    actual workbook I was unable to exit from Excel (i.e. the
    Application.Quit
    didn't seem to work). I'll try to come up with a more simple
    reproducible case
    for you, but for now your suggestion doesn't get me around my problem.
    
    Is there a function in the Teamlinks Integration I should be calling
    the exit from Excel.
    
    Thanks 
         
    Tommy

Hi Tommy,

If changing the Workbooks.Close to Workbooks.saved is not applicable to 
the customer, we can try calling into the XL7TLINT.XLA macro directory.
It is not the route that I would like to take.  However, this seems to be
the last resort.  Here is how to do it.

There is a Macro in XL7TLINT.XLA call "TLExit".  This is the macro that
gets run when the user chooses a File/Exit menu operation.  So, in the 
customer's macro, they will need to replace the "Application.Quit" with
"TLExit".  Since "TLExit" calls Application.Quit, there is no need to have
the second one.  In addition, they will need to set a "reference" to the
XL7TLINT.XLA.  The way to do that is to use the Tools/Reference... menu
operation in the Macro Edit mode.  From the Reference Dialog, "check" the
XL7TLINT.XLA entry.

After the above modifications, save the changes to the macro program and
exit.  It should work without crashing Excel.  However, there is one 
drawback with this workaround.  This is because the code now depend on the
integration being installed.  The customer's macro program will not run if
the integration is removed.  It will still work if the integration is only
"disabled".

Please have the customer try this workaround and let me know if it is 
acceptable to them.

Alfred///