When will VB6 be Unable to Run Under Windows

**Tech99** · Sep 13th, 2015, 03:18 PM

Originally Posted by fafalone

You're inputting them as hex right? &HxxBBGGRR, you can input the full range of 0-255 because 255 is FF. Not sure what you're talking about with the color picker dialog, MSPaint lets me enter 3-digit decimal numbers no problem.

No not in hex, just plain decimal values. Color chooser accepts only numeric digits. Definitely in W7/64 Finnish language version, color chooser has a bug in it.

gibra · Sep 13th, 2015, 04:31 PM

Originally Posted by Schmidt

The IDE will work without that Admin-setting, when the Project you will start-up will use only
"already existing and stable COM-Interfaces which already have proper entries in the registry"
(e.g. those of the built-in OCX-stack - and typelibs which ship with VB6).

Honestly I do not understand the meaning of what you write.
VB6 works without any problems. Always.

**Schmidt** · Sep 13th, 2015, 04:51 PM

Originally Posted by gibra

Honestly I do not understand the meaning of what you write.
VB6 works without any problems. Always.

Nope, that simply cannot be, when you consider the following:

1) Why do you think it is necessary, to run e.g. regsvr32.exe elevated (to make it succeed)?
Right, it wants to write to registry-hives which require "Admin-access-rights".

2) Now, keep in mind that the VB6-IDE supports a whole lot of development-modes, as well
. as project-types, where it will need the very same access-rights, to be able to write to
. those (COM-related) registry-hives itself.

I hope you see as clearly as I do, that the point #2 above is not going conform with your:
- "works without any problems. Always."
statement.

Your statement denies the fact, that the VB6-IDE is *dependent* on full access-rights
to certain areas of the registry (to work properly and behave as expected in scenarios,
where it has to register and unregister COM-stuff - sometimes even temporarily).

Olaf

**fafalone** · Sep 13th, 2015, 05:04 PM

Originally Posted by Tech99

No not in hex, just plain decimal values. Color chooser accepts only numeric digits. Definitely in W7/64 Finnish language version, color chooser has a bug in it.

There's two different things; the various 'Color' entries in the Properties window for VB stuff, which you can manually enter the string in hex (&HxxBBGGRR), then the color chooser common dialog, something entirely different. That sounds like a pretty big bug to be unpatched.. it's fine on Win7 x64 US.

**Tech99** · Sep 14th, 2015, 06:32 AM

Originally Posted by fafalone

There's two different things; the various 'Color' entries in the Properties window for VB stuff, which you can manually enter the string in hex (&HxxBBGGRR), then the color chooser common dialog, something entirely different. That sounds like a pretty big bug to be unpatched.. it's fine on Win7 x64 US.

I reported this color chooser common dialog bug to Microsoft, as early as beginning of the 2010. Correction to the problem is still 'non existing' - it seems that MS is not interested this.

Color properties in VB IDE works ok, but color chooser under color properties/combobox drop down and palette tab displays blank white in manifested IDE.

**Jonney** · Sep 17th, 2015, 07:52 AM

Originally Posted by Schmidt

OLE-Drag&Drop is designed and capable to work "cross-process".
And when the two Processes (e.g. whilst dragging something out of a running *.vbp,
hosted within VB6.exe -> onto Explorer.exe), then those two processes will work
together in the Ole-Drag&Drop Operation only, when their "User-Credentials they
were started with" do match.

And when VB6.exe runs with Admin-credentials (elevated) - but Explorer.exe does
run under the "normal User-account", then the Ole-Operation will fail - or just
"doesn't react" (not throwing the expected Events).

Same thing (sometimes) with 'Ole-Automation' (e.g. working cross-process against
the Excel-, Outlook- or Word-ObjectModels from an elevated running VB6.exe).

So, to test these cases from within a "running *.vbp" (from within the VB6.exe-Hostprocess)
you should start VB6.exe (just this time) - in non-elevated mode (with normal User-credentials).

But this came up quite often over the last months (and perhaps years) - a forum-search
should bring those threads up.

Olaf

Few talent guy worked out a packed version of VB6.EXE to support Drag-Drop on VBIDE (Administrator Mode):
http://bbs.csersoft.net/thread-33-1-1.html

**lmstearn** · Dec 1st, 2016, 11:40 PM

Originally Posted by dilettante

Windows XP

Windows XP is no longer supported...
So XP is no longer a viable development platform any more than Windows 95.

Yes, they said they have withdrawn support for those. But, in W10 [1607], right click an executable and find under the Compatibility Tab that the program can be run in compatibility mode for as far back as Windows 95! Pseudo-Support? :P
...
Still toying with the idea of putting it on W10, is there a recommended guide for that somewhere?

Thread: When will VB6 be Unable to Run Under Windows

Thread Tools

Display

Re: When will VB6 be Unable to Run Under Windows

Re: When will VB6 be Unable to Run Under Windows

Re: When will VB6 be Unable to Run Under Windows

Re: When will VB6 be Unable to Run Under Windows

Re: When will VB6 be Unable to Run Under Windows

Re: When will VB6 be Unable to Run Under Windows

Re: When will VB6 be Unable to Run Under Windows

Tags for this Thread

Posting Permissions