|
Thanks, Jack. It's nice to know it's something someone else has seen  .
Software Zen: delete this;
|
|
|
|
|
Hello
I am creating a dialog based application using MFC. I want that, by just executing my program, after it draws itself on computer screen, it should automatically start its work (i.e. scanning pc). Till now I have to click a button on dialog after it draws itself on computer screen, to start scanning. Can anyone tell me how can do it?
Waiting for kind responce...
We Believe in Excellence
|
|
|
|
|
|
OnInitDialog() gets called before the dialog is displayed...
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"
|
|
|
|
|
Aqueel wrote: I want that, by just executing my program, after it draws itself on computer screen, it should automatically start its work (i.e. scanning pc).
At the end of the OnInitDialog() method, call PostMessage() with a user-defined message. In the handler for that message, start your work.
Instead of a message, you could call AfxBeginThread(). This would allow your UI to remain active while the work was still going on.
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
Thank you very much. It works...
We Believe in Excellence
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
