Thread: need example code for a win32 window

It may seem to you that this question should be really simple to answer, but it isn't.

The last question is fairly easy to answer: If you want a good quality compiler that isn't going to cost you a penny, try the free version of Visual Studio C++:
http://msdn2.microsoft.com/en-gb/express/aa975050.aspx

When it comes to writing Windows applications, it is quite a bit of work to get just a plain window on the screen, never mind menus and such. There are libraries that do this work for you, so you only need to fill in the "necessary" bits to do your application. The above compiler comes with MFC, but other third party libraries exist too - wxWidgets is one that allows your application to work both on Windows and Linux/Unix.

Also, I would recommend getting a book on the subject of programming Windows if you are planning to do it seriously.

--
Mats

Is "deian" related to "Debian" in any way? If so, what are you doing looking for Windows code?

There are many cross-platform GUI or widget libraries around. wxWidgets is written in C++, so it could be difficult to use in C, though I don't know, having never tried it. You could go with something else like GTK+ or Qt. Search around if you're curious. There's a lot out there.

There are some people who will tell you you need thrid party libraries to get a window up and running, they would also tell you to use some sound library to make your computer Beep(). There aae plenty of minimal windows skeletons that will do exactly what you want. Ill post the one I use for my personal projects when I get home tonight.

As for 'free' compilers/IDE's , the most popuilar ones are Dev-C++, CodeBlocks , OGRE, and LCC. most of those are based on the gcc compiler. LCC uses its own compiler.

All of those come with 'skeleton' windows applications, so it shoudl be fairly easy to get up and running. Dont mess with MFC, its evil, EVIL I tell you EVIIIIIILLLLL!.

Dont mess with MFC, its evil, EVIL I tell you EVIIIIIILLLLL!.

We can tell by your signature . . . though that was a little . . . more strongly stately than your signature.

popuilar

I know that's popular, but when I was scanning your post I read it as peculiar. It's pretty funny when you read it like that . . .

There's also MSVC Express.

Originally Posted by abachler

Dont mess with MFC, its evil, EVIL I tell you EVIIIIIILLLLL!.

Opps, you told!

Betterkeep a look out for some mighty evil remote controlled trains, MFC is sending one your way. Hard to miss as they are over 3Km long.......

(I create industrial PC systems and use a variety of tools, including MFC).

MFC is alright in situations where raw performance isnt an issue. Decisions on switching tracks can be made (im guessing) on multiple second or minute timescales. The stuff I work with is pretty much pushing the limits of commercial hardware even with highly optimized code. I suggest 'normal' C/C++ to new programmers because the majority of MFC programmers Ive talked to take it as a personal attack when I try to explain to them that MFC has too much overhead to perform well at compute bound tasks. If you cant program using the windows API and you need pre-supplied classes to do everything for you, then I present for your consideration that perhaps C/C++ isnt the right language for you. Try Visual Basic or J#.

More specifically, most industrial applications (I used to work as an industrial engineer) only need to make state transitions on the millisecond timescale, hence why the PLC-500 is plenty fast. Dont get me wrong, Im nto saying MFC isnt FUNCTIONAL, im saying its SLOW, at least compared to pure C/C++ or assembly.

And pure WIN32 development takes too long, makes it too easy to for an inexperienced coder to break and has no advantage over MFC in rich client apps.

MFC has its uses. Your dislike of it appear to cloud your judgement on MFC's uses.

I use the best tools that will get the required results. I do not care if it is MFC, WIN32, VB or C#.

>>I suggest 'normal' C/C++ to new programmers because the majority of MFC programmers Ive talked to take it as a personal attack when I try to explain to them that MFC has too much overhead to perform well at compute bound tasks.

Your opinion, which, in my experience is incorrect. Ever actually coded commercial apps in MFC?

Check my posts from 2001, when I felt like you.

Luckily I am no longer young enough to know everything.

Originally Posted by dwks

I know that's popular, but when I was scanning your post I read it as peculiar. It's pretty funny when you read it like that . . .

Aoccdrnig to rscheearch at an Elingsh uinervtisy, it deosn't mttaer in waht oredr the
ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteer is
at the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit
porbelm. Tihs is bcuseae we do not raed ervey lteter by it slef but the wrod as a wlohe.

theForger's win32 Tutorial got me up and started on pure/vanilla win32 in just a few hours. I recommend going through that first. Aftewards its just a matter of using google, these forums, and MSDN (mostly in that order, then later on once you learn how to woo/trick MSDN search into returning results that are actually useful, it may become your first resort). Unfortunately, as the others hinted at, this is a dying artform, as hand-coding win32 GUIs is painstakingly unrewarding when it takes inverse proportional time to break your code as it did to create it. So for more practical, applications programming, I suggest a third-party widget library such as wxWidgets or others of that nature(and as others also hinted at, when at all possible, stay away from MFC).

Originally Posted by deian

ok guys, look what i want! i'm a telecom & electronics engineer. all i want is to write a simplest win32 application which could command a hardware via parallel port (or maybe serial, i don't know yet) when i choose an option from a pop-up menu/when i enter some data from the keyboard, to show some error messages if the hardware does not work properly and other thinks like that. since the C is the only language i know i thougt that maybe C++ or visual C under windows might help me. but it seems that i have to study it seriously and this will take me some time. do you know another way ?

Do you want the simplest to write or simplest in the amount of actual code it contains? That's two different things most of the time.

With MFC (for example), you can cobble together something that has a few menus, and writes a few things to the window, etc, etc, in a few minutes, and adding a bit more to deal with for example saving/loading from files isn't too complicated.

With pure Win32, you need an event-loop, and you need to deal with each event in a sensible way (ok, so most of them you can ignore and just pass along to the next level). But it gets more difficult to add more code later on, in my experience (but I'm not really a Windows programmer - most of my work is to do with drivers and low-level stuff).

I _THINK_ you will find that the serial port is easier to manage from a windows user-mode, as the parallel port tends to be "owned" by the printer driver. Serial ports are a little bit more flexible in their use. Again, I've never really used the serial port on a Windows machine (except for debugging purposes in a driver, and I just wrote directly to the port, ignoring any ownership - you can do that in a low-level driver, but not at user-level).

--
Mats

What do you define as "precise timing" - Windows isn't VERY precise timingwise (not if you look at "worst case" - it is much less bad on average than worst case).

Of course, if by "precise timing" you mean "within a few milliseconds", Windows should be fine.

Microsecond timing in Windows is almost impossible, and sub-microsecond you can forget now and forever.

And yes, you are correct, you can't (trivially) use inport/outport in user-mode. There are ways to allow you to access certain ports directly, but if you use the serial port, you should be able to do things without ever touching the hardware at all - just use the Windows API on the COM-port. [Search for "Windows serial" in this forum, and you'll find a few examples of how to do that].

--
Mats

Originally Posted by novacain

And pure WIN32 development takes too long, makes it too easy to for an inexperienced coder to break and has no advantage over MFC in rich client apps.

Depends on the programmer... I don't even think MFC is faster to develop with