|
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.
|
|
|
|
|
Normski wrote:
WTL Windows Template Library (only downside it's not *YET* supported by microsoft).
Do you really feel that someone could easily start to learn WTL or ATL without understanding MFC? Wouldn't a solid foundation in Win32 be more appropriate for starting out with WTL?
-Nick Parker
|
|
|
|
|
MFC won't die. It may not be used for new projects and may not be developed futher, but it won't die. There are too many legacy projects that depend on it, and it's just too expensive to convert them to something else. Even COBOL and FORTRAN are still used extensively.
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
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"
|
|
|
|
|
I've been looking into DirectX lately, more specifically Directdraw (even though technically speaking that doesn't exist anymore), because i wanted to sort of mimic the GUI of a certain game. This game has a menu on startup which is built up out of several bitmaps, all placed neatly together so they form one image. Then there is the menu on it which is formed by just drawing over the main image, rectangles that contain the text for the menuitem, so the menuitems must have a background to match the main screen. When you move your mouse over one of these items, the bitmap can change so the text appears to highlight or whatever. Now i have two questions:
1) Why did they break appart the main background image in several pieces? I mean, what reason could there be? Why didn't they just make the background image one large bitmap and then just draw the menu over it, so they wouldn't have to assemble the pieces of the background image first?
2) When you put the pieces of the background image together, you get an image of 640 by 480 pixels. Now, in the game you can switch resolutions, for example to 1024*768. So this would mean the bitmap would get stretched, how do you do this in DirectX? Is there a function, or do you have to write your own function to calculate how many pixels will be representing one pixel now?
Thank you for your help.
P.S.: i do have a theory for the first: The measurements of the pieces can all be divided by 16,32,64 or whatever, basically most pieces (also for game textures) are either 32*32,64*64,128*128,128*256,256*256 so maybe they just wrote a function that only handles certain dimensions of bitmaps like PaintBM256by256(). But i would think it would be easy to detect the size...
Kuniva
--------------------------------------------
|
|
|
|
|
Kuniva wrote:
Why did they break appart the main background image in several pieces? I mean, what reason could there be?
I'm not familiar enough with DirectDraw to be certain, but if the app is (or was planning to) use 3D acceleration for the 2D parts, then the author was just making sure that the image pieces will play nice with video card capabilities, particularly older cards. For example, the Voodoo 3 doesn't support texture sizes larger than 256x256.
- Mike
|
|
|
|
|
ah thanks! thats probably it really, the game is pretty old already
Kuniva
--------------------------------------------
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
