Skip to main content

[archive] Vista - activex controls

  • April 3, 2007
  • 7 replies
  • 0 views
D

[Migrated content. Thread originally posted on 22 March 2007]

We are testing Vista and have realized that we can no longer register the activex controls that we release without executing the runtime as an administrator. We are using a C$SYSTEM call to regsvr32.

If we execute the runtime as an administrator (option in the icon or in the right mouse click menu), the controls register fine. If not, they don't get registered. After much research on the web, this is a commonly known "feature" of Vista.

Does anyone know of a way to get around this? Or another way to register controls? I don't want to force users on Vista to execute the runtime as an administrator...

Thanks,
Rob

    7 replies

    D

    [Migrated content. Thread originally posted on 22 March 2007]

    We are testing Vista and have realized that we can no longer register the activex controls that we release without executing the runtime as an administrator. We are using a C$SYSTEM call to regsvr32.

    If we execute the runtime as an administrator (option in the icon or in the right mouse click menu), the controls register fine. If not, they don't get registered. After much research on the web, this is a commonly known "feature" of Vista.

    Does anyone know of a way to get around this? Or another way to register controls? I don't want to force users on Vista to execute the runtime as an administrator...

    Thanks,
    Rob
    Hi,

    Search the forum for "The process of determining if a control is installed" posted by Gisle - a good resource. He has another way of registering controls by calling DllRegisterServer of the AX control.

    Hope this helps. I would be interested to know how you get on. We will be testing our apps on Vista soon and we will have the same problem.

    Please keep us posted.
    D

    [Migrated content. Thread originally posted on 22 March 2007]

    We are testing Vista and have realized that we can no longer register the activex controls that we release without executing the runtime as an administrator. We are using a C$SYSTEM call to regsvr32.

    If we execute the runtime as an administrator (option in the icon or in the right mouse click menu), the controls register fine. If not, they don't get registered. After much research on the web, this is a commonly known "feature" of Vista.

    Does anyone know of a way to get around this? Or another way to register controls? I don't want to force users on Vista to execute the runtime as an administrator...

    Thanks,
    Rob
    An alternative yes, but it will not help for his issue, which is a matter of privileges. There is an API mechanism to let an application run itself in another security context than it actually is, but that would nevertheless involve administrator username and pwd. So not of much help that either am I afraid.
    D

    [Migrated content. Thread originally posted on 22 March 2007]

    We are testing Vista and have realized that we can no longer register the activex controls that we release without executing the runtime as an administrator. We are using a C$SYSTEM call to regsvr32.

    If we execute the runtime as an administrator (option in the icon or in the right mouse click menu), the controls register fine. If not, they don't get registered. After much research on the web, this is a commonly known "feature" of Vista.

    Does anyone know of a way to get around this? Or another way to register controls? I don't want to force users on Vista to execute the runtime as an administrator...

    Thanks,
    Rob
    I had the same problem and atm the only one work-around i found is deactivate 'Use User Account Control (UIC) to help protect your computer' check in the user account management. Doing that all work like Windows XP.

    I know is not a nice solution skip the new feature of Vista, but i didn't know what to do in waiting for some solution from Acu in the new Runtime Vista compatible (i hope).
    D

    [Migrated content. Thread originally posted on 22 March 2007]

    We are testing Vista and have realized that we can no longer register the activex controls that we release without executing the runtime as an administrator. We are using a C$SYSTEM call to regsvr32.

    If we execute the runtime as an administrator (option in the icon or in the right mouse click menu), the controls register fine. If not, they don't get registered. After much research on the web, this is a commonly known "feature" of Vista.

    Does anyone know of a way to get around this? Or another way to register controls? I don't want to force users on Vista to execute the runtime as an administrator...

    Thanks,
    Rob
    Donant,

    Unfortunately, I don't believe a fix is coming about this from Acucorp. I think it's a Vista "feature". I think we'll need to be looking for Microsoft to give more flexibility or perhaps a third party solution. If I'm wrong, I'm sure Gisle will chime in and give us good news!

    Rob
    D

    [Migrated content. Thread originally posted on 22 March 2007]

    We are testing Vista and have realized that we can no longer register the activex controls that we release without executing the runtime as an administrator. We are using a C$SYSTEM call to regsvr32.

    If we execute the runtime as an administrator (option in the icon or in the right mouse click menu), the controls register fine. If not, they don't get registered. After much research on the web, this is a commonly known "feature" of Vista.

    Does anyone know of a way to get around this? Or another way to register controls? I don't want to force users on Vista to execute the runtime as an administrator...

    Thanks,
    Rob
    This is indeed a Vista feature, ACUCOBOL-GT is not the only environment getting into this kind of trouble. If we can find a good solution to this is too early to tell yet.
    D

    [Migrated content. Thread originally posted on 22 March 2007]

    We are testing Vista and have realized that we can no longer register the activex controls that we release without executing the runtime as an administrator. We are using a C$SYSTEM call to regsvr32.

    If we execute the runtime as an administrator (option in the icon or in the right mouse click menu), the controls register fine. If not, they don't get registered. After much research on the web, this is a commonly known "feature" of Vista.

    Does anyone know of a way to get around this? Or another way to register controls? I don't want to force users on Vista to execute the runtime as an administrator...

    Thanks,
    Rob
    I think that at a minimum, if there were a way to prompt the user to enter their vista admin user and password for a one time registration of activex controls, that it wouldn't be so bad.
    Gisle, do you know if the DllRegister windows api call does this?
    D

    [Migrated content. Thread originally posted on 22 March 2007]

    We are testing Vista and have realized that we can no longer register the activex controls that we release without executing the runtime as an administrator. We are using a C$SYSTEM call to regsvr32.

    If we execute the runtime as an administrator (option in the icon or in the right mouse click menu), the controls register fine. If not, they don't get registered. After much research on the web, this is a commonly known "feature" of Vista.

    Does anyone know of a way to get around this? Or another way to register controls? I don't want to force users on Vista to execute the runtime as an administrator...

    Thanks,
    Rob
    I presume you know of the executable RunAs? If you use this one to execute the runtime, e.g.:

    runas /user:localmachinename\\administrator wrun32 cobolapp

    The user will be prompted for a password, but the instance of wrun32.exe will have administrator privileges and as such be able to do what you want.

    Another alternative, more complex but gives you much more control is to use the CreateProcessWithLogonW. You will spawn of a separate version of the runtime, but nevertheless, it is given the required privileges.

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement