I have a VB6 IDE successfully running under Windows10. Wierd problem described below.

[eday@aymbus.com]

I have been successfully doing support for my VB6 Solution, for my largest customer, for the past 12-18 months.

By chance, we found an issue where running the code from the IDE closes the modal form much faster (2 seconds vs. 14 seconds), than running the compiled version of that same code using the same data and same machine.

Have any of you run into a problem like this? If so, did you solve the issue and how?

The pseudo code goes something like:

Form 1 is loaded as a Modal form.

The user makes edits to the data.

User presses the Update button.

Update routine updates all of the relevant files.

A MsgBox gives the user the option to print or skip printing the GL transaction report.

Update Routine calls Report #1 MODALLY to display the General Ledger consequences of the updating.

Report is created and displayed using DataDynamics ActiveReports Viewer 2.0

Viewer displays, allows printing of the report.

The user clicks the Done button on the Viewer and closes it.

Code execution returns to and continues from Form1. THIS IS WHERE THE DELAY OCCURS.

After the 14 second delay, a MsgBox gives the user the option to print or skip printing the Physical Inventory Update report.

And life goes on. BTW: the 12 second delay does make a difference to my customer.

[qvb6]

When your app is slowing, are other apps slow as well? What about the start menu? Is it slow as well?

Close VB6 IDE(important), and repeat the compiled version test. Is it slow as well? Restart, then without running the VB6 IDE, run your compiled EXE and see if it's slow.

My guess is that it might be related to Windows Themes. See this thread for details.

Also, starting with VB6+SP3, in a compiled app, Timer events fire when there is a MsgBox or a modal form. In the IDE, it doesn't regardless of service packs. So make sure that you apply SP6.

PS: I asked the moderators to move this thread to VB6 forum since it doesn't belong in the CodeBank.

[eday@aymbus.com]

First, thanks for the quick reply. to answer your questions:
1. No other apps are not slow, nor is the start menu.
2. This was found by my User and he does not have the IDE at all, only the .exe. He experienced it. I was able to duplicate it on my machine.
3. I will check out the Windows Themes thread, and follow up with results.

[qvb6]

It looks like your problem is not related to themes. Try running your app as Admin, and see if it's faster now.

Also, if you want to print debug messages from the EXE, please use OutputDebugString() API function, which sends the output to this external debugger(No installation needed, just unzip, and run as ADMIN). The function wrapper below would cover both printing in the IDE and the EXE:

Public Declare Sub OutputDebugString Lib "kernel32" Alias "OutputDebugStringA" (ByVal lpOutputString As String)
 
Public Sub DebugPrint(ByRef s As String)
    Debug.Print s
    OutputDebugString s & vbCrLf
End Sub

The only drawback is that it doesn't support Print syntax, so you can't use ",;"

[eday@aymbus.com]

qvb6,

Your help with themes thread actually helped a lot. An unrelated to my problem, in that thread, sparked off some weird ideas to solve the issue.

First weird idea, opening anything VBModal from inside a form that is already itself opened as VBModal, is strictly bad juju and not to be done.

Second weird idea, a do loop and DoEvents could pause Form1's code execution until the first report I was trying to print could be finished by the user and function.

So instead of calling the Active Report modally, I created a panel with the ARViewer and a Done button on it.
Form1 then sets a Boolean variable to false, displays the hidden panel, and goes into a do loop and DoEvents checking for the Boolean variable to be set to true.

User then prints/exports to Excel/emails the report and clicks the Done button which re-hides the panel, and sets the Boolean variable to True.

Form1 code falls out of the do loop and program execution continues.

[eday@aymbus.com]

qvb6,

Your help with themes thread actually helped a lot. An unrelated to my problem, in that thread, sparked off some weird ideas to solve the issue.

First weird idea, opening anything VBModal from inside a form that is already itself opened as VBModal, is strictly bad juju and not to be done.

Second weird idea, a do loop and DoEvents could pause Form1's code execution until the first report I was trying to print could be finished by the user and function.

So instead of calling the Active Report modally, I created a panel with the ARViewer and a Done button on it.
Form1 then sets a Boolean variable to false, displays the hidden panel, and goes into a do loop and DoEvents checking for the Boolean variable to be set to true.

User then prints/exports to Excel/emails the report and clicks the Done button which re-hides the panel, and sets the Boolean variable to True.

Form1 code falls out of the do loop and program execution continues.