|
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.
|
|
|
|
|
Use a timer instead. At the appropriate spot, call SetTimer(500). In the timer-handling function, if any of the secondary threads are still active (the secondary threads will have indicated to the primary thread that they have finished), output the dot. Does that make sense?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
-- modifed at 11:28 Thursday 25th August, 2005
|
|
|
|
|
yes it makes sense. I will never attempt to use Sleep() as a timer again.
I am going to try that now.
Thanks.
|
|
|
|
|
I know this is a really broad question, but...
How would I go about programmatically determining whether a given network connection is wireless or not?
For that matter, what is the "tried and true" method for enumerating network connections? Google searches yield different methods, all with varying degrees of reliability...
One big stumbling block is that if the OS is Win32, my code's gotta be able to get that data reliably. That is, anything from the original Win95 to Win2K3. Although to be frank I'm not terribly concerned about determining whether a connection is wireless or not on a 95 box (are there even adapters that ship with 95 drivers?)
|
|
|
|
|
Daniel Desormeaux wrote:
How would I go about programmatically determining whether a given network connection is wireless or not?
Good question, especially since the wire, or lack thereof, is part of the Physical layer of the OSI.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Windows can determine it. I'm assuming there's gotta be something that can be queried to get to the same information.
|
|
|
|
|
I'm not in disagreement, but I do not know what it would be. If you find out, it would make for a good CP article.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
|
I have an issue where I have a function that takes an HDC and draws to it. Instead of just displaying the data in a window, I want to write it to a bitmap file. I don't want to show the window at all, so I'm hoping that I can do this with a hidden window some how. I've tried calling GetCurrentBitmap() on the CDC object and that did not give me a valid bitmap. I also tried the following:
hDC = GetDC(hDCWnd);
hBmp = CreateCompatibleBitmap(hDC, 500, 500);
SelectObject(hDC, hBmp);
MyFuncToDraw(hDC);
CBitmap* bitmap = CBitmap::FromHandle(hBmp);
but that only gave me a blank bitmap. Does anyone have any idea how I can get a valid CBitmap so I can save it to a file? Is this even possible??
-- Rocky Dean Pulley
-- DreamSys Software
-- http://www.dreamsyssoft.com
|
|
|
|
|
You need to create a memory dc
hDC = GetDC(hDCWnd);
// create the memory dc
HDC hdcMem = ::CreateCompatibleDC(hDC);
hBmp = ::CreateCompatibleBitmap(hDC, 500, 500);
// select the bitmap into the memory device context instead
HBITMAP hbmpOld = (HBITMAP)::SelectObject(hdcMem, hBmp);
// pass the memory dc handle instead
MyFuncToDraw(hdcMem);
CBitmap* bitmap = CBitmap::FromHandle(hBmp);
... after done
::SelectObject(hdcMem, hbmpOld);
::DeleteDC(hdcMem);
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
