|
this is exactly what have happened!!
but I just couldn't see it.....Thank you so much for all your help!
|
|
|
|
|
I use VC.net to create a MFC regular DLL. VC wizard generates a skeleton for me.
// CVCMFCDLL_App
BEGIN_MESSAGE_MAP(CVCMFCDLL_App, CWinApp)
END_MESSAGE_MAP()
// CVCMFCDLL_App construction
CVCMFCDLL_App::CVCMFCDLL_App()
{
// TODO: add construction code here,
// Place all significant initialization in InitInstance
}
// The one and only CVCMFCDLL_App object
CVCMFCDLL_App theApp;
// CVCMFCDLL_App initialization
BOOL CVCMFCDLL_App::InitInstance()
{
CWinApp::InitInstance();
return TRUE;
}
All these is not what I expected. I want to export my own Class. What are those for? may I delete all those stuff?
Why it contains a "theApp"? it is really confused!
|
|
|
|
|
xianwuluo wrote:
I want to export my own Class.
Sounds like you want an MFC Extension DLL then.
xianwuluo wrote:
What are those for?
Initialization, globals, whatever.
|
|
|
|
|
I don't want MFC extention DLL. regular is enough. I just found these skeleton useless.
I delete these stuff, it works!
another problem:
I don't want my class private member to be exposed to Client. I know I have to use .def file to export class. but when I do
EXPORTS
; Explicit exports can go here
CMyClass
I got compile error. CMyClass is not recongnized by compiler.
|
|
|
|
|
xianwuluo wrote:
I don't want my class private member to be exposed to Client.
Isn't that what private means ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Yes, Client can not access to it. but as the private variables or functions are listed in .h file. Client is going to include in this application. It would be nicer, that Client only see public stuff of the class.
|
|
|
|
|
Two notes:
1) C++ does name mangling to encode additional information in exported symbols. You need to list the mangled names in the .def file, or use Microsoft-specific commands in your code to make this happen. (hint: the latter is far easier than the former)
2) Because of the way C++ works, you can't expose a class without exposing private member variables. If you don't want your client to see these when reading the header file, then you'll need to go to some extra effort to make that happen - export a class that doesn't have the private member variables, but internally uses the class that does to do what it needs. Do a search for "facade pattern" if that doesn't make sense.
|
|
|
|
|
|
hi,
does anyone know how to call a program(such as mspaint, word or any other program/ executable present) from our vc++ application. i.e. on executing an application it should call another windows program.
thanks
aditya
|
|
|
|
|
See here.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
DavidCrow wrote:
See here.
... plus the spawn functions.
|
|
|
|
|
Why? Those are simply a holdover from the days of Unix. Unless you are doing 16-bit work, they have no place in Windows development.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Aditya Rao wrote:
executing an application it should call another windows program.
you can try this also www.codeproject.com/system/newbiespawn.asp[^]
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
I have a simple question. I have inherited a VC++ application that uses a 3rd party software (Roguewave Stingray) for its GUI grids, tree controls, etc. Since I inherited this app, plus the fact that I don't have much experience writing large pc-based apps from scratch, my question is:
What is the advantage of using 3rd party tools for grids, tree controls, etc.? Doesn't MFC have this functionality built in, or is it just not robust enough for large-scale apps? My app is approx. 8 years old, so is the answer to this question different now than it was 8 years ago?
Thanks for any feedback.
Pat
|
|
|
|
|
normally, one buys a toolkit if the current one does not offer what she really want.
for example, there is/were not real spreadsheet/grid control in MFC, and companies ( roguewave, dundas, ... ) decided that there was a market to build such a control to sell to us programmers.
MFC is good enough for applications that stay within a strict MFC/Windows application guideline, and is simple enough so that it does not have a stepp learning curve. The problem arise when the programmer wants to do something that is not supported or already done ( grid, advanced editors, trees, ... ); the programmer has to learn more than just the class structures, and basic win32 API, he has to learn how to program with low(er) level API than MFC, and for some companies, having someone spend days or week developping a control that can be bought is not good meny spent.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
Hi!
Here's the problem: I have a chat window using a rich edit control, with a vertical scrollbar. When a user is scrolled to the bottom of the rich edit, the text should automatically scroll down when new text is added. But if the user is scrolled up higher in the rich edit, reading something that was written awhile ago or catching up on the chat or something, it should not scroll down.
If I just do nothing to it, everything works except that until the user actually physically scrolls to the bottom ONCE, the text will not automatically scroll down.
I've tried using the GetScrollInfo function to get the max scroll position and compare it to the current position, but the info gleaned by GetScrollInfo doesn't seem to coincide to itself; i.e. when the user has fully scrolled to the bottom, nPos != nMax, the max seems to be a lot larger than the position.
What to do??
Thanks!
Kelly Ryan
|
|
|
|
|
I am using VC++ in visual studio dotNET. I wrote a program that has several threads running doing stuff, and a dialog box that is updated by the main thread. Everything works well when I hit "run" in the development environment. But when I run the executable, everything seems fine, but if I so much as click anything outside of the dialog box window, the window does not get updated again, it does not repaint, and it appears to have stopped responding. The other threads, however, are still running, and when they finish, the main window is updated with all the information that it should have been displaying along the way. I am a little new to the ms environment, and I thought that running through the development environment and running the .exe should be the same. Does anyone know what is going on here?
I could really use some help.
|
|
|
|
|
DaveHuber wrote:
...and a dialog box that is updated by the main thread.
Does the main thread own the dialog box?
DaveHuber wrote:
...but if I so much as click anything outside of the dialog box window, the window does not get updated again, it does not repaint, and it appears to have stopped responding. The other threads, however, are still running, and when they finish, the main window is updated with all the information that it should have been displaying along the way.
This is a classic problem with threads. Read here and here for more.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
the program is just a dialog box that is owned and exclusively updated by the main thread
|
|
|
|
|
So has the main thread created these other threads to do some work? How are they communicating with the main thread?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
The main thread starts the other threads with afxBeginThread, they go and do their work, and then when they're done, the last thing they all do before killing themselves is fill a global array with their results. but while they are working, the main thread doesn't seem to be doing anything. I don't understand why it works ok when I run it through development environment, but not otherwise.
|
|
|
|
|
DaveHuber wrote:
...but while they are working, the main thread doesn't seem to be doing anything.
What should the main thread be doing?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
the main thread should be updating the window. It is basically just printing in a field on the window whenever a thread starts or stops. I use SetWindowText to put my message in the right place, and then UpdateWindow to update the window. Until all the threads are done, the main thread is sitting in a loop: print the message if there is one ready to be printed, Update the window, and sleep for a little while. That is all the main thread is doing while the other threads are doing their work.
|
|
|
|
|
DaveHuber wrote:
Until all the threads are done, the main thread is sitting in a loop: print the message if there is one ready to be printed, Update the window, and sleep for a little while.
Ouch! This is not the way for a well-behaved multithreaded application to be. Anytime you have to use Sleep() to get the threads to work together, rest assured that there is a definite design problem. The secondary threads should post a message back to the main thread when they have something to report (e.g., started, processing, stopped). Have you read these two articles:
User Interface Threads
Worker Threads
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
-- modifed at 11:22 Thursday 25th August, 2005
|
|
|
|
|
no, I'm not using sleep to get them to work together, they would work fine without it. I am using it for other reasons, albeit probably bad ones... I am printing one more '.' on a line every half second until the main thread sees that the other threads have all terminated. It is cheesey progress indicator. I didn't know how to make it wait for 500ms other than putting it to sleep for that long.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
