hi there,
is it any method to use VB6 to disable a hardware and after that enable it?
Regards.
Printable View
hi there,
is it any method to use VB6 to disable a hardware and after that enable it?
Regards.
What hardware?Quote:
Originally Posted by elsc
some hardware like wireless network adapters, bluetooh devices....
Do you want to disable them for sometime or forever for a particular user?
I would suggest that you just remove the hardware rather than try and write code for it.
disable for sometime and need to enable it in sometime too
i can open the device manager and disable it, so it must have the way to do in vb right?
is there any better idea other than remove the hardware?
Not necessarily. There are many things you just can't code in VB. Does your program need the ability to disable and re-enable the hardware while it runs? Or do you just want the hardware not enabled when your program is running? What is the hardware? Some kinds can be turned on and off from software easily.Quote:
Originally Posted by elsc
Reopening this thread as no response has solved the issue.
Well, I've been working with a serial (RS232) connection and facing denied access to the communication port while debugging the code in the IDE. This issue is caused by a problem in the code that fails to close the COM port before stopping. As a temporary solution, I've had to close the IDE in order to release the COM port.
I was considering that once the error code is captured, I could disable/remove the serial port and then enable/reinstall it again. By doing so, the need to close the IDE would no longer be necessary.
So, how to perform this task through code ?
If it can be disabled via device manager it can indeed be disabled by code... however some brief research on this topic suggests it is not possible on a 64bit machine through the WOW64 layer (i.e. from a 32bit app). You *could* get around this by calling the 64bit DLLs, but it's very, very difficult. Another option would be twinBASIC, which wasn't around in 2006 when this question was asked.
Here's an example of how to do it in C#: https://stackoverflow.com/questions/...disable-device
And here's the relevant APIs you'd need in 64bit VBA/twinBASIC:
Code:Public Enum Setup_DIGCF
DIGCF_DEFAULT = &H00000001 ' only valid with DIGCF_DEVICEINTERFACE
DIGCF_PRESENT = &H00000002
DIGCF_ALLCLASSES = &H00000004
DIGCF_PROFILE = &H00000008
DIGCF_DEVICEINTERFACE = &H00000010
End Enum
Public Type SP_DEVINFO_DATA
cbSize As Long
ClassGuid As UUID
DevInst As Long
Reserved As LongPtr
End Type
Public Enum Setup_DICSF
DICS_FLAG_GLOBAL = &H00000001 ' make change in all hardware profiles
DICS_FLAG_CONFIGSPECIFIC = &H00000002 ' make change in specified profile only
DICS_FLAG_CONFIGGENERAL = &H00000004 ' 1 or more hardware profile-specific
' changes to follow.
End Enum
Public Enum DI_FUNCTION
DIF_SELECTDEVICE = &H00000001
DIF_INSTALLDEVICE = &H00000002
DIF_ASSIGNRESOURCES = &H00000003
DIF_PROPERTIES = &H00000004
DIF_REMOVE = &H00000005
DIF_FIRSTTIMESETUP = &H00000006
DIF_FOUNDDEVICE = &H00000007
DIF_SELECTCLASSDRIVERS = &H00000008
DIF_VALIDATECLASSDRIVERS = &H00000009
DIF_INSTALLCLASSDRIVERS = &H0000000A
DIF_CALCDISKSPACE = &H0000000B
DIF_DESTROYPRIVATEDATA = &H0000000C
DIF_VALIDATEDRIVER = &H0000000D
DIF_MOVEDEVICE = &H0000000E
DIF_DETECT = &H0000000F
DIF_INSTALLWIZARD = &H00000010
DIF_DESTROYWIZARDDATA = &H00000011
DIF_PROPERTYCHANGE = &H00000012
DIF_ENABLECLASS = &H00000013
DIF_DETECTVERIFY = &H00000014
DIF_INSTALLDEVICEFILES = &H00000015
DIF_UNREMOVE = &H00000016
DIF_SELECTBESTCOMPATDRV = &H00000017
DIF_ALLOW_INSTALL = &H00000018
DIF_REGISTERDEVICE = &H00000019
DIF_NEWDEVICEWIZARD_PRESELECT = &H0000001A
DIF_NEWDEVICEWIZARD_SELECT = &H0000001B
DIF_NEWDEVICEWIZARD_PREANALYZE = &H0000001C
DIF_NEWDEVICEWIZARD_POSTANALYZE = &H0000001D
DIF_NEWDEVICEWIZARD_FINISHINSTALL = &H0000001E
DIF_UNUSED1 = &H0000001F
DIF_INSTALLINTERFACES = &H00000020
DIF_DETECTCANCEL = &H00000021
DIF_REGISTER_COINSTALLERS = &H00000022
DIF_ADDPROPERTYPAGE_ADVANCED = &H00000023
DIF_ADDPROPERTYPAGE_BASIC = &H00000024
DIF_RESERVED1 = &H00000025
DIF_TROUBLESHOOTER = &H00000026
DIF_POWERMESSAGEWAKE = &H00000027
DIF_ADDREMOTEPROPERTYPAGE_ADVANCED = &H00000028
DIF_UPDATEDRIVER_UI = &H00000029
DIF_FINISHINSTALL_ACTION = &H0000002A
DIF_RESERVED2 = &H00000030
End Enum
Public Type SP_CLASSINSTALL_HEADER
cbSize As Long
InstallFunction As DI_FUNCTION
End Type
Public Enum SetupDeviceStateChange
DICS_ENABLE = &H00000001
DICS_DISABLE = &H00000002
DICS_PROPCHANGE = &H00000003
DICS_START = &H00000004
DICS_STOP = &H00000005
End Enum
Public Type SP_PROPCHANGE_PARAMS
ClassInstallHeader As SP_CLASSINSTALL_HEADER
StateChange As SetupDeviceStateChange
Scope As Setup_DICSF
HwProfile As Long
End Type
Public DeclareWide PtrSafe Function SetupDiGetClassDevsW Lib "setupapi" (ClassGuid As UUID, ByVal Enumerator As String, ByVal hWndParent As LongPtr, ByVal Flags As Setup_DIGCF) As LongPtr
Public DeclareWide PtrSafe Function SetupDiEnumDeviceInfo Lib "setupapi" (ByVal DeviceInfoSet As LongPtr, ByVal MemberIndex As Long, ByRef DeviceInfoData As SP_DEVINFO_DATA) As BOOL
Public DeclareWide PtrSafe Function SetupDiDestroyDeviceInfoList Lib "setupapi" (ByVal DeviceInfoSet As LongPtr) As BOOL
Public DeclareWide PtrSafe Function SetupDiGetDeviceInstanceIdW Lib "setupapi" (ByVal DeviceInfoSet As LongPtr, DeviceInfoData As SP_DEVINFO_DATA, ByVal DeviceInstanceId As LongPtr, ByVal DeviceInstanceSize As Long, RequiredSize As Long) As BOOL
Public DeclareWide PtrSafe Function SetupDiSetClassInstallParamsW Lib "setupapi" (ByVal DeviceInfoSet As LongPtr, DeviceInfoData As SP_DEVINFO_DATA, ClassInstallParams As Any, ByVal ClassInstallParamsSize As Long) As BOOL
Just a hint, you may use Microsoft DevCon console utility. Quick download.
Well, you may intercept API calls of specific command to see how it works if you want to reproduce via VB6 (e.g. with API Monitor).
Or: source code of it.
Here is exact sequence allowing you to find and disable device by name in CMD with DevCon:
Now, remove everything after last "\" with "\" itself, and add * (don't ask why, it's some kind of bug in DevCon)Code:devcon find "*" | find /i "SVGA"
PCI\VEN_15AD&DEV_0405&SUBSYS_040515AD&REV_00\3&61AAA01&0&78 : VMware SVGA 3D
Note: to disable some devices, API should be called with privileges of at least "Trusted Installer", otherwise DevCon will return "device not found" which actually also means "access denied" if you see the appropriate attempt in its response. You may get such permission with System Informer software, or with such code.Code::: to disable
devcon disable PCI\VEN_15AD&DEV_0405&SUBSYS_040515AD&REV_00*
:: to enable
devcon enable PCI\VEN_15AD&DEV_0405&SUBSYS_040515AD&REV_00*
I've got a RunAsTrustedInstaller utility, twinBASIC x86/x64, which has a few extra features (and compiled binaries in repo releases) vs my original VB6 version.
I'm working on a device manager with enabled/disable/eject/remove commands now, inspired by this thread. Going good so far, successly listed all hardware classes and devices, should be done in the next couple days.
I don't remember ever running into this using the MSComm control. It seems to reliably close the handle when deallocated after programs run within the IDE are interrupted.
Are you using an early version from before SP 6?
Or is this one of those "I'm so clever, look me calling APIs Ma!" scenarios? If so you probably face headaches similar to those with failing IDE runs of programs with subclassing hooks.
Not even sure who that's addressed to. Are you complaining someone wants to write code to do something programmatically when some other program can do it for them?
I thought I was pretty clear.
Fix the problem by ensuring that the handle gets closed when the program gets interrupted in IDE runs. MSComm controls do that for you.
Even if bashing things with a hammer made sense, when is the program going to do it? Once dead it can't disable or enable anything.
My thought was a separate quick utility to manually shut it off when the main program broke; I've done that kind of thing before. I don't know enough about MSComm to know if that could close old sessions so just gave a general solution to the question asked, since it's far more widely useful anyway. If you're debugging active errors and crashes from the IDE it's virtually impossible to ensure a section of code always runs before you have to nuke the run entirely.