|
You can put any code into a DLL. It is even simpler and better when the DLL code did not use MFC or ATL (it can then be used by any application).
I'm not sure if I understand your second question. Do you mean to create a DLL with functions used by multiple applications where each application uses only a subset of exported functions?
If so, the answer is yes.
To list the symbols exported by a DLL you can use the DUMPBIN[^] command line tool (located in the VC\bin directory) with the /EXPORTS option.
You can also use the GUI tool Dependency Walker (depends.exe)[^].
Both will list the names of exported functions and variables. The Dependency Walker can also show the parameters when present in the DLL (has been build with C++ decoration).
|
|
|
|
|
Already answered in the ATL forum.
|
|
|
|
|
hi
i want to control parts of my code with #ifdef directive,so I need to control a #define directive before!
something like this:
if (condition)
#define active
and in other files I will check whether "active" is defined or not!
ok,I can put :
#define active
in header file then use it in others cpp files
but I cant use if statement in header!
how can i do that?
cheers,
peiman
|
|
|
|
|
Please explain your problem using an example. It is (at least for me) unclear.
Common practice is to define a value somewhere (inside a header file or even passing it to the compiler via command line; optionally by project settings).
So assuming you use ACTIVE as boolean condition (defined or not defined):
#define ACTIVE
#ifdef ACTION
#endif
#ifndef ACTION
#endif
But this won't work if there is a code condition like
if (condition)
Then you have to use similar code conditions in all other places.
Note also that I have used all upper case for the defined value because this is common practice.
To know about conditional inclusions using the preprocessor see Preprocessor directives - C++ Tutorials[^].
|
|
|
|
|
p3im4n wrote: but I cant use if statement in header!
Why not? A header is just a text file that gets included into, and compiled as part of, some source code. It is quite common to do something like:
#if defined(foo)
#endif
#define foo
#include <header file>
|
|
|
|
|
I am doing Interprocess communication between a C console app and C++ Windows app
The C console app is the parent process
I have the Window handle (main window MainFrame) of the C++ child app I use SendNotifymessage
to tell the child app that console app has data for it in shared storage
The First time I do this all is well
The Second time around I have created a modless dialog box with a Crichedit control
it is at this time where I get a asseration from the SendNotifyMessage in the console C app
The assetration is dlgcore.cpp
at the parent GetSafeHWnd
lpDialogTemplate = (DLGTEMPLATE*)GlobalLock(hTemplate);
m_nModalResult = -1;
m_nFlags |= WF_CONTINUEMODAL;
AfxHookWindowCreate(this);
hWnd = ::CreateDialogIndirect(hInst, lpDialogTemplate,
pParentWnd->GetSafeHwnd(), AfxDlgProc);
#ifdef _DEBUG
dwError = ::GetLastError();
#endif
}
CATCH_ALL(e)
{
|
|
|
|
|
pParentWnd is NULL or the window has not yet been created (it's HWND member is NULL).
I can give no more help because you did not show the relevant code parts (the posted code seems to be MFC source).
|
|
|
|
|
The Hwnd is a main Window it is set to a value
i'll go into assembly mode and double check
|
|
|
|
|
Why are you using pParentWnd->GetSafeHwnd() to get your HWND? You should just use GetSafeHwnd() on its own.
|
|
|
|
|
thing is I don't know how the code got to dlgcore.cpp The Hwnd is a MainWindow
Okay thanks
|
|
|
|
|
It gets to dlgcore by virtue of your call to SendNotifyMessage, at which point it asserts because the handle you sent it is not valid.
|
|
|
|
|
But the Window Handle is a Main or Mainframe Window
I did a FindWindow api call
To get the handle As the parent is a C console app and it did work once before I created the modless dialog box in the child process
|
|
|
|
|
But you are calling pParentWnd->GetSafeHwnd() in a console app which makes no sense. What does pParentWnd point to?
|
|
|
|
|
Hi
I am at work now however the only thing I can think of at this point is that I have to use DuplicateHandle to make the child main window accessible to the parent
|
|
|
|
|
No, you just need to find its handle by one of the enumerate functions, or get the child to pass it back in some way. A handle is just a pointer used to identify a Window so you can send messages to it. To be honest, I am not exactly clear about what you are trying to do beyond the basic SendMessage function.
|
|
|
|
|
"EnumThreadWindows"
My questions in Windows is a threadID unique throughout Windows
Thanksp
|
|
|
|
|
I would assume yes, since in the case of EnumThreadWindows, the threadid is the only information Windows needs to return the information.
|
|
|
|
|
Richard got the same assertion I believe this has to do with sharing window handles between threads
I am going to use duplicate handle and see if that resolves the issue
Thanks
|
|
|
|
|
ForNow wrote: I believe this has to do with sharing window handles between threads
I don't think so. You should be able to send a message to a Window from anywhere.
|
|
|
|
|
I want to call an external application (created by me) using ShellExecute or CreateProcess. It is just an update application for the main app. The problem is, what ever I tried I failed to get window focus back to my main app when the process (update app) is terminated. I created a simple MFC/SDI app that calls window's notepad under "C:\windows\notepad.exe" which suffers from the same problem, just to show you what I mean. I need the parent window -which is the main app- to be disabled (like a modal dialog box behaviour) until the new app -update application- will finish its job.
PS:If I do not disable the main window with EnableWindow(FALSE) I have paint corruption with windows XP and back when I move the update application.
Here an example:
http://www.filedropper.com/shellexecutecreateprocesstestapp[^]
sdancer75
|
|
|
|
|
You could wait on the process handle returned by ShellExecute or CreateProcess, this will let you know when the child process has exited.
Then you could use BringWindowToTop to bring your main application window to the foreground.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Thank you for your answer.
As you can see in the code I am using WaitForSingleObject. I tried to use also the BringWindowToTop with no luck. What ever I tried I had no success.
sdancer75
|
|
|
|
|
sdancer75 wrote: As you can see ... What ever I tried I had no success.
We cannot see anything, you need to show your code and explain where it goes wrong.
|
|
|
|
|
|
But what is a problem for you to attach a piece of code to your post?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
