Quote Originally Posted by gibra View Post
The fact is that the issue is not so clear and simple.
There isn't a something to say: do so and doesn't have to use Run As ...
So, I guess I'm correct with my assumption, that your elevated running Setup-Process will
- not apply any special rights to certain Registry-Hives
- and will also not apply lowered Access-Rights to the Root-Folder of a VB6-installation

In this case (as your video shows quite clearly) - your setup-process did nothing to solve the
necessity to run the IDE "as Admin".

Your assumption (or suggestion), that after using your Installer, the "running as Admin" setting
would not be necessary anymore, is a wrong one.

The same problem (as it became apparent at the first start of your fresh installed IDE in your vid at 8:00),
still applies - and is just "waiting for the next time you run into it" (which is for example, when you develop,
debug or compile ActiveX-Dlls, or ActiveX-Exes - depending on their "Project-Compatibility or BinComp-Settings" -
or when you use complex ProjectGroups - or try to run two isolated IDE-Instances in a Cross-Process-Debugging-
scenario.

I think it was important, that we established that now for the other readers of this thread:
The "Run as Admin setting is needed!" (when you use the VB6-IDE in more complex scenarios).

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).
So it's a "less capable-mode" (COM-wise) - but one which still can be useful, e.g. when you want
to test stuff as the already mentioned Ole-Drag&Drop for example.


Olaf