Instead, consider using the platform specific APIs, such as the Linux APIs for C or the Win32 API on Windows. The benefit is that you will be able to get the information, such as the information about hardware (I am not sure, whether you will be able to dig that much information or not).
IMO, changing the behaviour of a common control (such as CFileDialog) is a bad idea. Your users have grown to expect that common controls behave in a certain way, and changing that only makes your program less intuitive.
Perhaps you should think upon why you want to change this behaviour.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
The problem is maintaining consistency, I'm using an IFileDialog to open files on some computers, it all works as expected in win10, but on others win7 ultimate, the Open button has an arrow with a dropdown menu that adds a second option, "show previous versions".
i have a mfc application project in Visual studio 2010. it is a GUI infact.
i want to get communication with a mini circuit signal generator device. the device has a dll file named "mcl_gen64.dll
i want to use functions of that dll in my code but i dont have any idea how to do this
any idea please?
"ConnectByAddress" is a function in .dll file
when i run the code although the dll file is being loaded but i get this error:
Unhandled exception at 0x770115ee in fdll.exe: 0xC0000005: Access violation.
I have no idea why the error occurred, beyond saying that is is caused by a bad address reference somewhere. And the only way to find out where it occurred is by using the debugger. Are you certain that the parameter 0x01 that you send to the ConnectByAddress function is valid? Check the documentation to see what that function is supposed to do, and what it is supposed to return.
To use functions from a DLL you have two choices: Early and late binding.
Link your application with the DLL by using the #import directive in one file (usually a source file using functions from the DLL) specifying the file name (usually without extension or with .lib), or add the .lib file to your project settings (Linker - Input).
Include the header file and call the functions defined in that file.
This is only necessary if the DLL might not be present when your application is executed or you do not have a .lib file. Then use LoadLibrary and GetProcAddress like in your above example. But check both return values to be not NULL. Have a look at the header file (if present), to know how to define the function prototypes. Example:
typedefint (__stdcall *ConnectByAddressfuncPtr)(short Addr);
ConnectByAddressfuncPtr LibMainConnectByAddress = NULL;
HMODULE hLib = LoadLibrary(_T("mcl_gen.dll"));
LibMainConnectByAddress = (ConnectByAddressfuncPtr)GetProcAddress(hLib,"ConnectByAddress");
Note that I have initialised the function pointer with NULL and checked it before calling the function. Note also the __stdcall in the prototype declaration. It defines the calling convention used by the DLL. You have to check which is used (by inspecting the header file or asking the provider). __stdcall is common but it might be also __cdecl.
All I can suggest is to check if the DLL exports the function "ConnectByAddress" (e.g. using the Dependency Walker (depends.exe) Home Page[^] or executing dumpbin /exports path_to_dll on the command line; dumpbin is in the VC/bin folder) and trying it with different calling conventions like __cdecl.
I would use the Dependency Walker because it shows also the calling convention for the exported functions.
You omitted to mention that in your reply to me. If that function pointer is null then it will cause the error you have seen. You need to check the function name that you are trying to get the address for, does it actually exist in the dll?