Windows Installer Popup on vb6 compiled app start.

[axisdj]

Hello,

I have a customer who installed my vb6 created ActiveX exe app. They are running Windows10 Home

The install goes fine, but when they launch my vb6 app they get a 'Windows Installer' dialog as seen attached.

Any clue what would cause this and how to fix?

Thanks

[OptionBase1]

If you have access to their machine, in the Event Log (Application Log I believe, but could be System) there should be an event from the Windows Installer that will usually note that an expected file or Registry value is missing. Sometimes simply placing a 0 byte file with the name/path of the file being sought is enough to make it stop.

That being said, I've seen it happen where you "fix" the problem, and Windows Installer pops up again. Check the event log, and now a different "missing" file is the culprit. Fix that one, and another "missing" file will show up as the culprit. My experience is that it will kick off the Windows Installer and simply log the "first" missing thing it encounters as the reason, so you may need to fix multiple missing files through this process.

[axisdj]

Hello,

So the event viewer says there is a problem with component {22056900-C842-11D1-A0DD-00A0C9054277}

A brief search shows it may be mswinsck.ocx.

Im using Inno setup, maybe I did not distribute the control properly

any guidance on this?

[qvb6]

That GUID doesn't exist in my system, which has VB6, so it's not the Winsock control. Search your own registry for clues, or open your VBP file in Notepad and look for it. Also, post the [Files] section of your InnoSetup script.

[AAraya]

I regularly hear of errors like this from my customers. In launching my application, a dialog box prompting them to install some other application comes up due to a missing file... However, my app does not require this file or this app to run.

The application install being prompted for can vary from Windows itself to an Office product to some other app I've never heard of. In looking into this many times over the years I see variations of this problem on many other product forums - it's not just my app and it's not just VB6 apps.

The only solution I've ever found is to completely uninstall or reinstall the application being prompted for in the install dialog. This works 100% of the time in resolving the issue for my users.

Since your case involves Windows itself, maybe your user can try a Window repair type install. I've had success with that approach.

[OptionBase1]

I don't have that GUID either.

A google search for that GUID turns up numerous references to MSCOMCTL.OCX, with Office 2003 possibly being involved as well. If your program's installation distributes that file, it probably clobbered the version that was already installed on the target device.

[axisdj]

OptionBase1 how would I resolve that?

My install only installs the mswinsk.ocx if it is not present in system. Here is the inno line. Anyone have suggestions?

Source: "Dlls\MSWINSCK.ocx"; DestDir: "{sys}"; Flags: onlyifdoesntexist regserver restartreplace sharedfile

Just thinking here would it be improper just to install the mswinSck.ocx into the app directory and not register it. Will that work?

[dilettante]

Stop using No-No Setup.

[qvb6]

OptionBase1 how would I resolve that?

My install only installs the mswinsk.ocx if it is not present in system. Here is the inno line. Anyone have suggestions?

Source: "Dlls\MSWINSCK.ocx"; DestDir: "{sys}"; Flags: onlyifdoesntexist regserver restartreplace sharedfile

Just thinking here would it be improper just to install the mswinSck.ocx into the app directory and not register it. Will that work?

Please remove "onlyifdoesntexist". What's happening is that the file is not copied, but Inno would still register it(Just in case it was left over from a previous install, and was unregistered), and perhaps the registry entries differ somehow, but I don't think so. Also, please don't install this file under {app}, it would break other programs. Here are the flags that I use for that file and most OCX files:

Source: Dlls\MSWINSCK.OCX; DestDir: {sys}; Flags: restartreplace sharedfile regserver uninsnosharedfileprompt

I use "UnInsNoSharedFilePrompt" flag because if the user uninstall my app, and it's the last one to use that OCX, the user is spared from responding to a confusing prompt that asks them if they want to delete the file, most users don't know how to respond to such a question. Answering Yes or No is both okay in this case.

[Schmidt]

I'd say: "Stop using any Setup" (aka: "make your App portable, using regfree-techniques")

For MSWinsock there should be enough (nearly compatible) Classes around in the meantime... (which one can compile-in directly)...
And for MSCOMCTL.OCX (which I think is the culprit - judging from your GUID), there's Krools replacement-OCX (which comes with a regfree Manifest).

Not to mention the RC5 (which you are familiar with), which can replace both dependencies above -
and could also be run regfree + it could replace your AX-Exe-Threading with "regfree STA-Dll-threading"...

Olaf

[axisdj]

qvb6 would I do the same for these?

Source: "vbfiles\stdole2.tlb";  DestDir: "{sys}"; OnlyBelowVersion: 0,6; Flags: restartreplace uninsneveruninstall sharedfile regtypelib
Source: "vbfiles\msvbvm60.dll"; DestDir: "{sys}"; OnlyBelowVersion: 0,6; Flags: restartreplace uninsneveruninstall sharedfile regserver
Source: "vbfiles\oleaut32.dll"; DestDir: "{sys}"; OnlyBelowVersion: 0,6; Flags: restartreplace uninsneveruninstall sharedfile regserver
Source: "vbfiles\olepro32.dll"; DestDir: "{sys}"; OnlyBelowVersion: 0,6; Flags: restartreplace uninsneveruninstall sharedfile regserver
Source: "vbfiles\asycfilt.dll"; DestDir: "{sys}"; OnlyBelowVersion: 0,6; Flags: restartreplace uninsneveruninstall sharedfile
Source: "vbfiles\comcat.dll";   DestDir: "{sys}"; OnlyBelowVersion: 0,6; Flags: restartreplace uninsneveruninstall sharedfile regserver
Source: "Dlls\MSCOMCTL.OCX"; DestDir: "{sys}"; CopyMode: alwaysskipifsameorolder; Flags: restartreplace uninsneveruninstall sharedfile regserver
Source: "Dlls\MSSTDFMT.DLL"; DestDir: "{sys}"; CopyMode: alwaysskipifsameorolder; Flags: restartreplace uninsneveruninstall sharedfile regserver
Source: "Dlls\COMDLG32.OCX"; DestDir: "{sys}"; CopyMode: alwaysskipifsameorolder; Flags: restartreplace uninsneveruninstall sharedfile regserver

[axisdj]

Olaf, looked profusely for a mswinsk.ocx class in vb, and could not find one.

Retooling my app with krools replacement will be a daunting task, but Ill look into it.

to keep things going I need solution to current problem, then can follow your suggested re-factorings.

This issue only appears on very few customers systems.

[Schmidt]

Source: "vbfiles\stdole2.tlb";  DestDir: "{sys}"; OnlyBelowVersion: 0,6; Flags: restartreplace uninsneveruninstall sharedfile regtypelib
Source: "vbfiles\msvbvm60.dll"; DestDir: "{sys}"; OnlyBelowVersion: 0,6; Flags: restartreplace uninsneveruninstall sharedfile regserver
Source: "vbfiles\oleaut32.dll"; DestDir: "{sys}"; OnlyBelowVersion: 0,6; Flags: restartreplace uninsneveruninstall sharedfile regserver
Source: "vbfiles\olepro32.dll"; DestDir: "{sys}"; OnlyBelowVersion: 0,6; Flags: restartreplace uninsneveruninstall sharedfile regserver
Source: "vbfiles\asycfilt.dll"; DestDir: "{sys}"; OnlyBelowVersion: 0,6; Flags: restartreplace uninsneveruninstall sharedfile
Source: "vbfiles\comcat.dll";   DestDir: "{sys}"; OnlyBelowVersion: 0,6; Flags: restartreplace uninsneveruninstall sharedfile regserver

No! Please remove this whole block, because those are system-Dlls which come preinstalled since Win-98...

Source: "Dlls\MSCOMCTL.OCX"; DestDir: "{sys}"; CopyMode: alwaysskipifsameorolder; Flags: restartreplace uninsneveruninstall sharedfile regserver
Source: "Dlls\COMDLG32.OCX"; DestDir: "{sys}"; CopyMode: alwaysskipifsameorolder; Flags: restartreplace uninsneveruninstall sharedfile regserver

As said, this is all contained in Krools CCRP-OCX (which comes with an SxS-manifest for regfree usage)

Source: "Dlls\MSWINSCK.ocx"; DestDir: "{sys}"; Flags: onlyifdoesntexist regserver restartreplace sharedfile

As said - use a compatible VB-Class-replacement for this (IIRC - wqweto has implemented a recent version for that)

Source: "Dlls\MSSTDFMT.DLL"; DestDir: "{sys}"; CopyMode: alwaysskipifsameorolder; Flags: restartreplace uninsneveruninstall sharedfile regserver

Probably not needed - usually introduced by ADO-Bindings to a VB6-DataGrid...
If you don't have such Bindings in your App, try to remove it from the dependency-list - and see whether your App complains.
If it does, do your "extended formatting" in another way.

Olaf

[dilettante]

That GUID is not any COM ID value used in mswinsck.ocx so trying to substitute another library might work but only by luck.

That's almost certainly an Installer component ID GUID, not anything to do with COM registration. His setup (like so many No-No setups) broke something and Installer detected that and is trying to repair the problem. Most likely it is stomping on something used by some version of MS Office.

Use a proper setup or an Installer MSI instead. Preferably the latter, drawing the components from the most recent Merge Modules rather than the live versions off your development system.

[Schmidt]

Olaf, looked profusely for a mswinsk.ocx class in vb, and could not find one.
https://github.com/wqweto/VbAsyncSocket

On his ToDo-list (at the bottom of the page), it seems he has a Winsock-compatible replacement "checked-in"...

Retooling my app with krools replacement will be a daunting task, but Ill look into it.

But it's a worthwhile one IMO...
At the place where I work, we wrote tools - which were then replacing VB.TextBox, VB.Combo with CCR14.TextBoxW, etc...
directly in the *.vbp, *.frm and *.ctl files.

But manual replacements on those VB-Code-Files (via NotePad++ or other good TextEditors) should work as well...
(depending on, what you're currently using from the MSComCtl.ocx - e.g. ImageLists or Toolbars with Images should better be replaced "by hand" in the IDE instead).

The MS-CommonDialog can (in our experience) be directly replaced with Krools CommonDialog-Class as well.

to keep things going I need solution to current problem, then can follow your suggested re-factorings.
This issue only appears on very few customers systems.

Well, that's always the problem I guess...
We delay necessary refactorings, due to "no time currently" ...
... and then we all try to fix constantly upcoming problems "with in sum much more time"
(accumulated over the recent months and years - compared to the time a proper refactoring would have cost us)

Olaf

[axisdj]

Ok Olaf understood...

Do you have the links for Krools replacement OCX, google search does not show it. I assume I will have to add that to my project and replace all instalnces of the controls with new one ( over 150 buttons etc)

I see you have a cTCPServer and cTCPClient in vbrichclient, could I replace my winsock control with those? I implemented my winsock control in a class by instantiating the frm with the control, to use as (createobject multithreaded) if needed.

WP

[axisdj]

Olaf,

I now remember why could not use : https://github.com/wqweto/VbAsyncSocket

When I try to replace my winsock ocx, I get a warning that his control can not be added to multithreaded projects.

As far as the common control replacement, I found it on GitHub and will put it on my toDO list, just wish I can handle this one customer now.

WP

[Schmidt]

Do you have the links for Krools replacement OCX, google search does not show it.

Hmm, if i google for your above word-sequence: [ Krools replacement OCX ]
... the first link in the search-result-page (pointing here into the Forum-CodeBank) should help, I guess ...

I assume I will have to add that to my project and replace all instalnces of the controls with new one ( over 150 buttons etc)

The Recent-OCX-version is here:
http://www.vbforums.com/showthread.p...mmon-controls)


Please download - rename - and uncompress it into a Folder-Lovation as e.g. C:\CCRP16\
Register it there via regsvr32 from SysWow64 as Admin.

Verify in a new IDE-Project, that you can indeed add and load the VB CCRP-OCX via the IDEs Components-Dialogue.
(you should get a "bunch of new Controls" in your IDEs Control-Panel) - then close this Project.

Now please open a new VB-StdExe-Project - and place only a normal VB-CommandButton on Form1 (with default-name Command1).
Now save the Form and the Project into a TestProject-Folder of your choice.

Now let's make "direct File-Replacements" (directly open the files with Notepad.exe or another Editor of your choice).
Here is the new content of the *.vbp File of this little ButtonReplacementTest-Project:

Type=Exe
Form=SimpleButtonTest.frm
Reference=G00020430-0000-0000-C000-000000000046#2.0#0#......WINDOWS\SysWow64\stdole2.tlb#OLE Automation
Object={0DF5D14C-08DD-4806-8BE2-B59CB924CFC9}#1.0#0; VBCCR16.OCX
Startup="Form1"
Command32=""
Name="Projekt1"
HelpContextID="0"
CompatibleMode="0"
... rest snipped

The line in blue above, needs to be added (below all other references or object-entries in a *.vbp), so that the Project can find the OCX when you later start the *.vbp again...

Though this part can also be done normally in the IDE (without Editor-Fiddling),
by adding the CCRP16 controls as a Component via the normal Dialogue (then saving the Project).

(we had to automate it, because our main-project has over 200 project-files).

Ok, what remains is a Replacment-Operation on your remaining file... (the *.frm):

VERSION 5.00
Begin VB.Form Form1
   Caption         =   "Form1"
   ClientHeight    =   3015
   ClientLeft      =   120
   ClientTop       =   465
   ClientWidth     =   4560
   LinkTopic       =   "Form1"
   ScaleHeight     =   3015
   ScaleWidth      =   4560
   StartUpPosition =   3  'Windows-Standard
   Begin VBCCR16.CommandButtonW Command1
      Caption         =   "Command1"
      Height          =   435
      Left            =   960
      TabIndex        =   0
      Top             =   1020
      Width           =   1035
   End
End
Attribute VB_Name = "Form1"
...rest snipped

The red line above is a replacment of the prior line-content, which was: Begin VB.CommandButton

And as said, you can automate at least these replacments on your *.frm or *.ctl files,
by simply reading the whole text-content of a given *.frm into a String - and then:
sNewContent = Replace(sContent, "Begin VB.CommandButton", "Begin VBCCR16.CommandButtonW")
...followed by writing sNewContent back into the *.frm file in question.

If done against your larger Project, you should try on a copy of it first...

I see you have a cTCPServer and cTCPClient in vbrichclient, could I replace my winsock control with those? I implemented my winsock control in a class by instantiating the frm with the control, to use as (createobject multithreaded) if needed.

The RC5-Socket-Classes are pure ByteArray-based workhorses - and not compatible with the Winsock.ocx and its Event-Interface.
So, why not go with Classes which claim to be compatible with it (to preserve your existent code and Event-Handler-implementations).

If in doubt, open a new thread for it - I guess wqweto whill chime in, when you ask about vbAsyncSocket-compatibility to Winsock.ocx...

Olaf

[axisdj]

All these changes are a bit overwhelming at this time(all suggestions taken, will put it on the to do list), I would like to focus on the issue at hand.

dilettante, you seem to understand what is happening with this issue, the customer did have office 2003 installed. Can you think of what I can try to resolve this?

An for the future what MSI installer do you recommend?

[Schmidt]

I now remember why could not use : vbAsyncSocket-Link on GitHub...

When I try to replace my winsock ocx, I get a warning that his control can not be added to multithreaded projects.

You should be able, to move wqwetos UserControl-Encapsulation (ctxWinsock.ctl)
over into a normal VB6 Class (by just copying the Code-contents from the UserControl to the Class).

Now (within your new Class - e.g. named Winsock.cls) - just remove all Event-Handler-Routines with "UserControl_" in their name -
with one exception:

Private Sub Class_Initialize() 'UserControl_Initialize()
    m_baRecvBuffer = vbNullString
    m_baSendBuffer = vbNullString
End Sub

Make the UserControl_Initilize() your new Class_Initialize() (as shown above)...
Ok - done - your new Winsock-Control replacement (in a normal VB-Class) is ready.

As far as the common control replacement, I found it on GitHub and will put it on my toDO list, just wish I can handle this one customer now.

Yeah - but please use the Forum-Links with the appropriate downloads I gave...
(because the instructions I've posted, were made for these Control-Binaries - not the sources).

BTW what I wrote about the "replacement-exercise" (VB.CommandButton vs. VBCCR16.CommandButtonW) -
it took me about 10 minutes, doing this live on my machine - including writing the article-post in parallel...
So it's not really that expensive and timeconsuming, to "get ready and prepare for this task".

If you put this off till "sometime later", then you'll probably never do it "earnestly"...

Olaf

[axisdj]

Thanks,

I have done this in the past and did not even think of it.. moving ctl to a class..

Thank you for your recommendations. I will move to these in the near future but at this point I need to keep sales going, and a complete overhall of common controls and winsock is too risky. A fresh install of win7,win8, win10 all work fine right now.

I would still like to know a patch for my current issue.