Read a line from a file HANDLE - C / C++ / MFC Discussion Boards

hello,

thanks for reply!!!!!
but i need a dynamic matrix!

can you help me?

thank you very much!
sunny

Is there any good way to do this or do I know a workaround of some sort?

To get the rect of the control or of the text itself?

// Control:
CRect oR;
CWnd *pStatic = GetDlgItem(IDC_THE_STATIC_CTRL);
pStatic->GetWindowRect(&oR);
ScreenToClient(&oR);

// bounding rectangle of static's text contents
CString cText;
GetDlgItemText(IDC_THE_STATIC_CTRL,cText);

CWnd *pStatic = GetDlgItem(IDC_THE_STATIC_CTRL);
pStatic->GetClientRect(&oR);

CDC *pDC = pStatic->GetDC();
pDC->DrawText(cText,&oR,DT_CALCRECT|DT_LEFT|DT_SINGLELINE|DT_TOP);
pStatic->ReleaseDC(pDC);

// oR now has the bounding rectangle needed to display the text.

onwards and upwards...

Wouldn't it be better to just make a memDC so the text itself won't show up on the control (it's already there ofcourse)? Or doesn't it do this anyway?

With the DT_CALCRECT the drawtext does not go to the screen it just calculates the rect.
John

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 />
/* My function... */<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 )   ////// ** crashes here ** /////<br />
        {<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 Hmmm | :|

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 Cool | :cool:

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.