|
The scenario is this:
In a 16 bit application A.app I am calling a 32 bit dll B.dll with a method exposed "DisplayDialog(HWND hWnd)".
DisplayDialog is called through the following sequence:
hDD = LoadLibraryEx32W(B.dll);
hDisplayDialog = (DISPLAYPPROC)GetProcAddress32W(hDD, "DisplayDialog");
CallProcEx32W(1, 1, hDisplayDialog, hWnd);
The resource for the dialog which I want to diaplay is in a 2nd 32 bit dll
C.dll. I am loading C.dll in B.dll using
hInstance = LoadLibrary(C.dll).
Then to display the dialog I am using this code in B.dll:
hDlg = CreateDialogParam(hInstance, MAKEINTRESOURCE(IDD_SOME_DIALOG), hWnd, (DLGPROC)SomeDlgProc, NULL);
ShowWindow(hDlg , SW_SHOWNORMAL);
SomeDlgProc is defined in B.dll.
hDlg is comming out as NULL.
GetLastError following the function call is returning 0.
But if I call B.dll from a 32 Bit app, it is working fine.
Please advice what is going wrong.
Thanks,
|
|
|
|
|
Hello,
I´ve made a Service Class based in the articles:
-"Creating a Simple Windows NT Service in C++" by Nigel Thompson on the MSDN.
-CNTService v1.06 - NT Service Framework By PJ Naughter
Well, everything was ok until the moment I´ve created this guy:
CFileFind *finder=new CFileFind(); (MFC class ... yes, I built it with MFC, probably a great error). I tried with other objects too and I got the same problem: in the debugger the service seams to stop responding and emiting "life" signals.
Does anyone know if the Service.exe controls the amount of memory for a Service (I suspect thats the problem), or if is there anything that I´m missing?
Thanks,
Dyrl
|
|
|
|
|
So what exactly is the problem:
Compiler error with CFileFind statement
Runtime error when creating CFileFind object
CFileFind object gets created but service stops responding
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
Well, it looks like the service stop responding ´cause the last message to the debuger was sent before the CFileFind was created. I put another msg after it´s creation and the msg didn´t came to the debbuger. So, I supose it is the service that stop responding.
|
|
|
|
|
IIRC (and I'm pretty sure I do), using MFC to write services is a big mistake. MFC assumes that you're running on a desktop in several places and there are all kinds of permission problems. The fact that your service just stopped suggests that this is maybe what's happened. If you're running a debug build, MFC throwing an assertion also has this symptom.
The two most common elements in the universe are Hydrogen and stupidity. - Harlan Ellison
Awasu 2.2 [^]: A free RSS/Atom feed reader with support for Code Project.
|
|
|
|
|
Hello Mr. Muraoka,
Is there any way to bypass these permitions problems? ´cause I´d like to use several functions from the MFC library, like those for support to UNICODE.
Thanks for your reply.;)
|
|
|
|
|
It's a long time since I looked at this but just Google for MFC and service. The problem is that MFC is pretty monolithic so if you use just a bit of it, you get all of it and you have no control over what a lot of it is doing. If you just need to handle Unicode strings, it's not that hard to do it yourself[^]
The two most common elements in the universe are Hydrogen and stupidity. - Harlan Ellison
Awasu 2.2 [^]: A free RSS/Atom feed reader with support for Code Project.
|
|
|
|
|
Taka Muraoka wrote: IIRC (and I'm pretty sure I do), using MFC to write services is a big mistake.
Which implies what exactly, that it can't be done or that it shouldn't be done? Several successful examples exist on the Internet, such as this one.
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
Hmm, I had actually seen that before but forgotten about it Simply writing a NT Service framework in MFC is probably no hassle, it's all the rest of the stuff you need your app to do that will be the problem.
It's many years since we got bitten on the ass by this one but I definitely remember doing a lot of reasearch into it and finding out that using MFC for a service was a Bad Move. There are certain areas in MFC that assumed you were running in a desktop and it would barf if you weren't i.e. running as a service. If you just want to use CString you can get away with it but we used MFC fairly extensively in our app and it just didn't want to work.
The two most common elements in the universe are Hydrogen and stupidity. - Harlan Ellison
Awasu 2.2 [^]: A free RSS/Atom feed reader with support for Code Project.
|
|
|
|
|
DavidCrow wrote: such as this one.
AFAIK, PJ's framework doesn't actually use MFC. You can use it just as well from non-MFC applications. It is possible to use MFC for serivces, as long as you steer clear of the windowing features.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote: AFAIK, PJ's framework doesn't actually use MFC.
Are classes such as CWinApp, CString, CSingleLock, and CStringArray no longer considered part of MFC?
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
Damn. Missed the header file 
Yes you're right, however CWinApp is not used in the library - only in the example. The only MFC classes he uses are non-windowing related (CString, CTime, CStringArray, CCriticalSection, CByteArray)
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Hi,
I've writen a Service with this Framework and Im alsoo using MFC
(since it was a port from a MFC SDI application) and don't have a problem with it.
I did however set the service to interact with the desktop.
Maybe you can set this option to see what happens.
Otherwise it could be some other error causes this problem.
In that case could you post the code where you think that the service hangs.
codito ergo sum
|
|
|
|
|
Ok guys,
I did it with the MFC classes and it´s ok. I used de CFileFind from MFC with a service created with the
"SERVICE_WIN32_OWN_PROCESS | SERVICE_INTERACTIVE_PROCESS" options.
The service is running with a timer inside. I´ve only noticed that you have to be very very aware of all memory leaks. You can get those 122 erros ("The data area passed to a system call is too small.").
Now I´m trying to use an ADO class from
href="http://www.codeguru.com/cpp/data/mfc_database/ado/article.php/c6729/"
but I´m getting more erros, but that is, maybe, for using ::CoInitialize in a Multi-thread application.
Thank you all. I´ve appreciated this discution.
|
|
|
|
|
I have owner drawn control using XP themes. Does anybody know whether is it better/recommended to call OpenThemeData() on creation of control and keep the handle for life of the object (or until theme is changed) or open then close it every time when painting occur ?
Thank you!
rrrado
|
|
|
|
|
I open it when I create the control and keep it for the life of the object. I've no idea if that's the correct way to do it or not, I just do it as I want my painting code to do as little as possible - so I don't do things like Open() there.
Check this[^] out, it makes things pretty easy when you're working with styles.
- Dy
|
|
|
|
|
I'm using another themes wrapper found here on codeproject (CThemeUtil).
I'm asking because I don't know whether it is more expensive to open theme data every time or maybe block some resources and memory by opened handle to theme for longer time than neccessary.
I've seen some XP controls opening theme data every time (for example CXPStyleButtonST).
So I'm also doing this and I haven't notice some slow drawing but haven't tried this on slower computer
rrrado
|
|
|
|
|
You can open a theme handle and keep it open. You'd only need to close/reopen it if your app gets a WM_THEMECHANGED message. Check out CThemeImpl in WTL for more details.
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | NEW!! PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
Hi
I have two applications - one written in c (dos window), the other in VC++, which need to communicate a variable value to each other. I currently do this by writing the value into a file from one application, and then reading it back in the other application.
This all works, but I was wondering whether there is a more elegant way of doing this?
Anyone help?
Thanks
Mike
|
|
|
|
|
There are several forms of Interprocess Communication (IPC). For example: clipboard, DDE, WM_COPYDATA, pipes, sockets, RPC.
What you have will probably work as long as you don't encounter the reader/writer problem.
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
Thanks for your help
What I have done is writen the data into a tempory file, and then renamed it to the actual file name that is required - this does appear to get over any file sharing problems that may have been encountered, and does work.
The old C program that I have is written using Quick C, and (as far as I know) is unable to respond to Windows Messages, or use the clipboard, sockets, etc.
In the VC app, I have set up a timer, which checks every 500mS (this is fast enough) to see if the file is there - if it is, it reads in the data. I am happy with the way the apps work at the moment, I just wanted to use a neater method of doing this, if possible.
Mike
|
|
|
|
|
You might want to look into the ReadDirectoryChanges function for your 32-bit application, so your timer does not have to exist. Your program will be 'signaled' when the file appears in the folder, assuming you totally control access to the folder itself - meaning, do not choose a common folder that gets a lot of activity, or your program will be notified for every file change.
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
But be careful if you are looking for changes on remote (network) shares. Both ReadDirectoryChangesW(...) and FindFirstChangeNotification(...) may experience problems when working with network shares - regarding path lengths and/or the remote system might not support notification of filesystem changes in such a manner. (Experienced this myself more than one time.)
IOW, if your application could be working with remote filesystems, it should have a polling interval as a fallback as well. Nothing worse than getting a call first thing in the morning from a site saying that your "real-time file processing application" stopped working this morning (they upgraded a *nix box that hosted one of the shares used the previous evening, and its network file support was slightly broken).
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Tip for new SUV drivers: Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
Is it possible to start a class member function as a separate worker thread or do I have to define the typical UINT MyThread(void* pParam) type of function?
If I do need to define the typical thread function, how can I encapsulate every thing into a class?
Thanks in advance!
|
|
|
|
|
Cteate static MyThread function in your class:
<br />
UINT CMyClass::MyThread(LPVOID param)<br />
{<br />
CMyClass* _this = (CMyClass*)param;<br />
<br />
return _this->DoSomeWork();<br />
<br />
}<br />
You can start thread this way AfxBeginThread(MyThread,this);
rrrado
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
