|
Hi,
thanks for sharing this url's 
bosfan
|
|
|
|
|
|
Hello.
I just wrote a code in C++. It should calculate something but for it we need a external File. Now I have to type in the whole Path. That's annoying.
Is there a possibility to open an "openfiledialog"?
Now I have this code copied but it won't work-.-:
OPENFILENAME ofn; char szFile[1000]; HWND hwnd = GetConsoleWindow(); HANDLE hf;
ZeroMemory(&ofn, sizeof(ofn));
ofn.lStructSize = sizeof(ofn);
ofn.hwndOwner = hwnd;
ofn.lpstrFile = szFile;
ofn.nMaxFile = sizeof(szFile);
ofn.lpstrFilter = "All\0*.*\0Text\0*.TXT\0";
ofn.nFilterIndex = 1;
ofn.lpstrFileTitle = NULL;
ofn.nMaxFileTitle = 0;
ofn.lpstrInitialDir = NULL;
ofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST;
if (GetOpenFileName(&ofn)==TRUE)
hf = CreateFile(ofn.lpstrFile, GENERIC_READ,
0, (LPSECURITY_ATTRIBUTES) NULL,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL,
(HANDLE) NULL);
Can you see there any mistakes or can you post a better code for it?
Is there even a possibility for it, but without using MFC or .NET?
Greets
PS: Sorry for my bad english. I'm from Germany.
modified 18-Jan-13 13:39pm.
|
|
|
|
|
What does won't work mean?
|
|
|
|
|
oh sry. I meant it doesn't work.
The compiler runs the Code and I get no errors. But it doesn't show the OpenFileDialog. Only the next command.
|
|
|
|
|
So you're getting to the CreateFile() method?
|
|
|
|
|
Just copied another code of the initalizon of the OPENFILENAME structure and it worked.
|
|
|
|
|
I have a Visual C++ workspace that has 2 projects (1 exe & 1 DLL).
I used Serge Wautier's tutorial ( Resource DLLs and Language Selection Menu[^] ) to create (multi-language) resource DLLs (satellite DLLs) branching off the exe.
Now I have a collection of strings in the DLL that are shared in other projects. I created a satellite DLL for that DLL but can't figure out how to load it on-demand just like the exe's satellite DLL.
He used:
HINSTANCE hDll = LoadLibrary(szFilename);
AfxSetResourceHandle(hDll);
void CLanguageSupport::UnloadResourceDll()
{
if (m_hDll!=NULL)
{
SetResourceHandle(AfxGetApp()->m_hInstance); // Restores the EXE as the resource container.
FreeLibrary(m_hDll);
m_hDll= NULL;
}
}
etc etc for the unloading/loading satellite DLLs for the exe.
but how to do the same for the DLL?
|
|
|
|
|
I think I got it working:
From VC2005 there's a function called AddResourceInstance() to chain DLLs. However am still using VC6 so this function doesn't exist.
So I just copied some code from a DLL project. The DLL main file contains these lines:
static AFX_EXTENSION_MODULE NEAR extensionDLL = { NULL, NULL };
DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
{
AfxInitExtensionModule(extensionDLL, hInstance);
new CDynLinkLibrary(extensionDLL);
}
This dynamically loads the DLL. If we put some of this code into the EXE project like so:
HINSTANCE hDll2 = LoadLibrary(szFilename2);
AfxInitExtensionModule(extensionDLL,hDll2);
new CDynLinkLibrary(extensionDLL);
After the AfxSetResourceHandle(hDll); //setting satellite DLL overriding EXE resources
Originally, the EXE would be the resource container, but AfxSetResourceHandle(satelliteDLL) will set loaded DLL as default resource container, overriding the EXE like.
We use the above extension DLL to chain (add-on) another resource DLL.
The only issues now is freeing the library/memory..
|
|
|
|
|
I am trying to compile libexif. Basically I have a requirement to read exif data from jpg.
In the README-win32.txt it is written as: "hack yourself a build system somehow. This seems to be the Windows way of doing things."! 
I installed MinGW and Msys. I am able to get the Msys prompt. It ends up in a "$" prompt. I tried changing directory to where I have the libexif code from within this prompt unsuccessfully. My compile system is Win 7. msysCORE version is 1.0.11.
|
|
|
|
|
|
Thanks a lot
|
|
|
|
|
You are welcome.
Veni, vidi, vici.
|
|
|
|
|
|
Wow, this looks nice, thanks a lot
|
|
|
|
|
I have a C++ MFC static library dll file. I have a VB.Net program that acts as the GUI and C++ does the grunt work.
I have just taken over this program, but never had an opportunity to do any debugging for the C++ part until today. Whenever I place a breakpoint in the cpp file and run the main program (VB) the breakpoint I placed in the cpp will not be hit according to the compiler.
I am wondering why that is? In the past I have been able to do so on different programs but I believe that was because the C++ dll was created as a COM dll. I am not familiar with MFC so I am at a loss.
By the way I have been searching but could not find any documentation on how to do this. Maybe there is so if you can point me in the right direction I would greatly appreciate that.
Can the MFC static library be able to be debuggable from within a VB app? If not, can anyone offer any debugging suggestions as to some how "step" through the C++ code?
If you need me to clarify anything or go into more depth I will gladly do so.
By the way before I forget the C++ functions are called within VB using the following formula.
Declare Function FunctionName Lib "DLL_Name.DLL" (parameters) As DataType
|
|
|
|
|
Clark Kent123 wrote: I have a C++ MFC static library dll file.
DLL stands for Dynamic Link Library, it is by definition not static. Also, you state below that it is a COM component, are you sure it is built with MFC classes? You also need to check that the final component was built with DEBUG on so that the debugger can match the object code with the source file. You could test this further by setting a breakpoint in the VB code at the point where it calls one of the C++ functions and see if you can single step into the DLL.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Thanks for the response.
It seems that I may need to clarify a few things. That is my fault. My original message may have skimmed over a few details.
The reason why I wrote MFC static library was because under the C++ properties page I have the following...
Configuration Type: Dynamic Link Library
Use of MFC: Use MFC in a Static Library
Use of ATL: Not using ATL
I have not have had a chance to work with MFC and because of that I am at a loss. What I have worked on in the past (completely different program) is the use C++ to create COM objects and that way make it aware in other programming environments such as VB. But this particular C++ program is not a COM object. Every time I try to load the DLL file in VB using the Add Reference it tells me this is neither a valid COM object or assembly.
I have not been in this situation before so this is left me scratching my head saying how do you debug this? Do you have any suggestions?
This is what I am attempting to do. I have my main VB program and I add the C++ solution to the main project. I place break points in the C++ program and when I step through the main (VB) program it does not halt within the C++ cpp file. Upon mouse over the breakpoint the compiler tells me "The breakpoint will not be currently hit. No symbols have been loaded for this document."
I made sure in the Configuration Manager that all the programs or solutions are defaulted to "Debug" setting.
Any suggestions?
|
|
|
|
|
One thing you could try is to set the C++ DLL as the start up project in your solution, get the VB program running, then attach the debugger to it. I have had success in the past doing that with C# and C++ DLLs.
|
|
|
|
|
I will give this a try and hope this gets me what I need. Thanks for the suggestion!
|
|
|
|
|
Clark Kent123 wrote: Every time I try to load the DLL file in VB using the Add Reference it tells me this is neither a valid COM object or assembly.
So you are not even at the point of being able to debug anything yet, since you cannot get to the library. In order to use a C++ DLL from VB.NET you need to make that library into a COM component, or provide a pure Win32 interface which you can then access via the Platform Invoke feature[^].
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
I had a feeling you were going to say that. I was hoping that I was wrong. So because this DLL is not "exposed" it limits my debugging severely. 
This makes things interesting now. Thanks for confirming this for me.
|
|
|
|
|
Clark Kent123 wrote: because this DLL is not "exposed" it limits my debugging severely
Well, more than that, it means you cannot even start to use it. As I said above you can only access it via COM, or through P/Invoke.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Yes, you are correct. In my VB program I am using the P/Invoke technique to call this library of C++ functions. But it's not fun that I can't debug it. 
Oh well. The original author did it this way and it's going to take so much work to make it a COM object. Not sure if I want to go down that path. But thanks for the info.
|
|
|
|
|
"Whenever I place a breakpoint in the cpp file and run the main program (VB) the breakpoint I placed in the cpp will not be hit according to the compiler."
When debugging managed code that calls unmanaged code, there's a setting (in Properties | Debug) called "Enable unmanaged code debugging". If this isn't checked, the debugger won't step into the unmanaged code.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
