|
 Great! Thnx
|
|
|
|
|
One solution is to get the rect of the entire edit windows and then use GetTextExtent() to take add and subtract unit size.
Kuphryn
|
|
|
|
|
Hi. I'm doing a project where I open a COM port with CreateFile() to do some device accessing. I have writing working fine, but now I'm trying to figure out how to read one line of text from the COM port. The function fgets() would be nice, but it's for FILE structures and I have a HANDLE pointer to the open file.
Is their either
a) a function to create a FILE structure from a HANDLE, or
b) an existing function that does what I want?
I have created a function that I thought would read a file, but it crashes in the Kernel on my call to ReadFile(). Besides, I feel stupid writing such a basic function that I think must be already part of the Win API
I post in this forum because I actually am doing this in an MFC program, and I'm open to MFC solutions.
Thanks in advance.
<br />
<br />
LPSTR ReadLine( HANDLE hFile )<br />
{<br />
char c;<br />
LPSTR szBuffer;<br />
unsigned int pos = 0;<br />
BOOL fContinue = true, fCR = false;<br />
LPDWORD lpBytesRead = 0;<br />
<br />
szBuffer = (LPSTR)malloc( 256 );<br />
<br />
if( szBuffer != NULL )<br />
{<br />
while( ReadFile( hFile, &c, 1, lpBytesRead, NULL ) != 0 && fContinue ) {<br />
switch( c )<br />
{<br />
case 0x0A:<br />
fCR = true;<br />
break;<br />
case 0x0D:<br />
if( fCR )<br />
{<br />
fContinue = false;<br />
fCR = false;<br />
}<br />
break;<br />
default:<br />
fCR = false;<br />
szBuffer[pos] = c;<br />
pos ++;<br />
if( pos == sizeof( szBuffer ) ) <br />
fContinue = false;<br />
}<br />
}<br />
<br />
szBuffer[pos] = 0;<br />
}<br />
<br />
return szBuffer;<br />
}
|
|
|
|
|
You may want to look at the function
FILE *_fdopen( int handle, const char *mode );
creates a FILE * from a raw file handle.
onwards and upwards...
|
|
|
|
|
Not working. The example for _fdopen in MSDN uses _open() to open the file that's passed to _fdopen.
_open() returns an int, but CreateFile returns a Windows HANDLE pointer. So, this is the type of function I want, but it's required arguments aren't what I have.
|
|
|
|
|
Reading from a COM port is not as straight forward as you might think. You have to create a thread that checks the port constantly for a "data received" signal. Whether you like it or not, you have to use ReadFile(). Check MSDN on serial communications because they have examples there.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Howzit BlueApples,
I am quite sure that your problem relates to the lpBytesRead variable that you use. You effectively create a DWORD pointer that points to memory location 0, OUCH !!!! It will crash...
Try this:
DWORD dwBytesRead = 0;
while( ReadFile( hFile, &c, 1, &dwBytesRead, NULL ) != 0 && fContinue ) ////// ** crashes
Cheers
|
|
|
|
|
I want to make an MFC program that allows me to enter a part number and then brings up information on that part. I'd like to allow the user to edit the part numbers after the program is complete. Where do I start and what is the best way to structure the program? Do I have to use a database? I'll have hundreds of part numbers.
Thanks
|
|
|
|
|
You posted this message on June 26 and Ryan Binns already gave you a reply and I agree with him. Yes you have to use a database. If you don't know database programing you have a learning curve ahead of you.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Toni,
I admire your depth of perception...
|
|
|
|
|
But I should I admit that you reach even higher depths of perception that I can't even dream of. I should really encourage you to write your own database from scratch. With you as their main competitor all the database providers will run out of business.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
I want to learn how to make MFC programs. I was hoping someone would refer me to some great books on the subject. I am a beginner at MFC, so something understandable would be a big plus.
Thanks
|
|
|
|
|
Programming Windows with MFC Second Edition by Jeff Prosise. Its huge, around 1300 pages, but very easy to understand and definitely worth it
Matt Newman
"Two things have come out of Berkley, Unix and Acid, we do not belive this to be a coincidence"
Linux sucks twice as fast and 10 times more reliably, and since you have the source, it's your fault. -Ca1v1n
Post best viewed with lynx
|
|
|
|
|
Learn Charles Petzold "Windows Programing" by heart.
Next trawl thru the MFC samples.
Look at other peoples code.
The most difficult aspect to MFC is getting this Window from another window.
Example:
Application
MainFrame
Document
View
Toolbar
DlgBar
DockingDialogBar
Combo
Some other Control (SOC)
Now take an example where you want to communicate to from SOC to any other element in the Windows app?
I will demonstrate this technique in an article I'm preparing, just for a note I ask the same question to Jeff Prosise at a Windows Development Conference an he could'nt give me the actual answer.
It's quite easy a simple map store at app level so you can get at any window with little indirection.
|
|
|
|
|
I recommend:
Programming MsVisual C++ Fifth Edition[^]
Authors:
David J. Kruglinski
George Shepherd
Scot Wingo
great book from Ms Press.
Daniel Cespedes
"There are 10 types of people, those who understand binary and those who do not"
"Santa Cruz de la Sierra Paraiso Terrenal!"
daniel.cespedes@ieee.org
|
|
|
|
|
I read in an Amazon.com review that MFC programming will soon be going by the wayside, is this true? I thought it was here to stay. what would would replace MFC to create Windows programs? I want to learn MFC programming, or should I focus elsewhere?
Thanks
|
|
|
|
|
i just wrote a program in good old turboC from 1994. languages may get old, but they'll never go obsolete.
*.*
|
|
|
|
|
I remember working with that! Must be a DOS program. How fast does it run on today's hardware? Must be blazing!
onwards and upwards...
|
|
|
|
|
Not likely that it will die out, anytime soon at least. There is too much code base and too many MFC developers. C# and .NET are really nice and I would recommend you looking at them too, Inside C# Second Edition by Tom Archer. But I wouldn't drop MFC yet.
Matt Newman
"Two things have come out of Berkley, Unix and Acid, we do not belive this to be a coincidence"
Linux sucks twice as fast and 10 times more reliably, and since you have the source, it's your fault. -Ca1v1n
Post best viewed with lynx
|
|
|
|
|
DaveE9th wrote:
I read in an Amazon.com review that MFC programming will soon be going by the wayside, is this true?
Too good to be true, I am afraid.
|
|
|
|
|
So what is the latest and greatest over MFC to design Windows based programs, C#? How about MFC.net? Would you recommend I start with MFC, or start with something newer and forget MFC? I'm trying to decide if I should spend the time trying to learn MFC. Decisions decisions...
Dave
|
|
|
|
|
WTL Windows Template Library (only downside it's not *YET* supported by microsoft).
For heavy duty desktop programming eg. Visio, Word, Excel, Point and Click or document centric appd. use MFC
For simple destktop windows apps use WTL ( very lightweight)
For controls use ATL. (lightweight no dll's to carry)
For web apps use ASP.NET
For lightweight console apps use straight C++ or C
For data-centric (form based ) apps use C#
These are my own opinions base on 10 year windowing programming experience other people may agree or disagree, the choice is yours.
|
|
|
|
|
Normski wrote:
For heavy duty desktop programming eg. Visio, Word, Excel, Point and Click or document centric appd. use MFC
Interestingly enough, none of these applications (except maybe Excel) were developed with MFC.
|
|
|
|
|
I heard that Word still has thousands of lines of legacy C...might be different for Word 2003, etc. but I sort of doubt it. That stuff is probably still lurking around there somewhere.
|
|
|
|
|
Nemanja Trifunovic wrote:
Interestingly enough, none of these applications (except maybe Excel)
True, this is because they were all best on code pre '92 a mixture of tight C message crackers, no doubt.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
