Printable View
could somebody help me with a basic code for a win32 application - a simple window with some pop-up menus, a entering/displaying of a message on the screen or a text in a window and so on) ? i know programming only C under DOS and therefore some links with some commented code would be wellcomed.don't forget to say me what compiler should i use(freeware preferably).
thanks.
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!.
We can tell by your signature . . . though that was a little . . . more strongly stately than your signature. :)Quote:
Dont mess with MFC, its evil, EVIL I tell you EVIIIIIILLLLL!.
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 . . .Quote:
popuilar
There's also MSVC Express.
Opps, you told!Quote:
Originally Posted by abachler
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.
Quote:
Originally Posted by dwks
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).Quote:
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.
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.Quote:
Originally Posted by deian
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
i downloaded the tutorial from theForger's win32 Tutorial , but i will read it later because right now i don't have so much time. i have at home a c++ programming book , i have already red it , but a lot of thinks are chinese for me(Jamsa's C/C++ Programmer's Bible) and to be onest i don't like how the thinks are explained there, and most of the thinks i think that i don't need. i would like to introduce in the window code instructions which program the port registers (something like inportb, outportb, i think more "hardware" than "software", but i'm trying to avoid assembly), but i don't know if that is possible in win32. i need also a precise timing(for the port data output). i cannot post the results from my tests because i want to work at the project later, but i want to gather as much tutorials as possible (at the time when i work i want to have all at hand).
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
Depends on the programmer... I don't even think MFC is faster to develop with ;)Quote:
Originally Posted by novacain
Hey guys. Programming using win32 API is not supported on visual c++ 2005 edition as there s no windows.h supplied with it. Is there any other way out ???????
Surely this is not right - the MFC library will NEED some Win32 API functions to work, and for a large part of it, it's supplied as source-code.Quote:
Originally Posted by cadcrazy
If you can't find a windows.h in your installation, perhaps you need to install "some more stuff", or you may need to install the "Windows SDK" - which is available separately, but for free, from Microsoft.
--
Mats
MFC dialog based application.Quote:
Originally Posted by deian
Serial ports are treated as files;
Open with 'CreateFile()' [COM1, COM2 are the 'file name']
Get current state with 'GetCommState()' (winbase.h)
Adjust settings, set state with 'SetCommState()'
Get timeout settings with 'GetCommTimeouts()' 'SetCommTimeOuts()'
Use 'WriteFile()' to send a msg through the port.
Use 'ReadFile()' to read from the port.
These are best used with an event 'CreateEvent()' and 'WaitForSingleObject()' to ensure the operation completes or error is returned.
Close port with 'CloseHandle()'
Timers (OnTimer() or WM_TIMER) msgs have low priority in the OS message queue and can be ignored. So timer resolutions under 10ms need a higher resolution timer like QueryPerformanceCounter()
i tried to compile menutwo.c file and those attached to it from theForger's win32 Tutorial. I included all the files in a project, but the IDEs from below show the following errors:
dev c++
compiler
C:\Users\deian\Documents\c_tutorial\files\source\m enu_two\menu_two.c In function `LRESULT WndProc(HWND__*, UINT, WPARAM, LPARAM)':
29 C:\Users\deian\Documents\c_tutorial\files\source\m enu_two\menu_two.c invalid conversion from `void*' to `HICON__*'
35 C:\Users\deian\Documents\c_tutorial\files\source\m enu_two\menu_two.c invalid conversion from `void*' to `HICON__*'
C:\Dev-Cpp\Makefile.win [Build Error] [../Users/deian/Documents/c_tutorial/files/source/menu_two/menu_two.o] Error 1
build log
Compiler: Default compiler
Building Makefile: "C:\Dev-Cpp\Makefile.win"
Executing make...
make.exe -f "C:\Dev-Cpp\Makefile.win" all
g++.exe -c ../Users/deian/Documents/c_tutorial/files/source/menu_two/menu_two.c -o ../Users/deian/Documents/c_tutorial/files/source/menu_two/menu_two.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include"
../Users/deian/Documents/c_tutorial/files/source/menu_two/menu_two.c: In function `LRESULT WndProc(HWND__*, UINT, WPARAM, LPARAM)':
../Users/deian/Documents/c_tutorial/files/source/menu_two/menu_two.c:29: error: invalid conversion from `void*' to `HICON__*'
../Users/deian/Documents/c_tutorial/files/source/menu_two/menu_two.c:35: error: invalid conversion from `void*' to `HICON__*'
make.exe: *** [../Users/deian/Documents/c_tutorial/files/source/menu_two/menu_two.o] Error 1
Execution terminated
code blocks
Switching to target: default
Compiling: ..\..\Documents\c_tutorial\files\source\menu_two\m enu_two.c
mingw32-gcc.exe: installation problem, cannot exec `cc1': No such file or directory
Process terminated with status 1 (0 minutes, 0 seconds)
i have also tried to compile some simple C codes for a DOS console application as a simple file and as a project, and they show "undefined type" errors at some functions, linker errors, or error like the one above (from codeblocks, altough cc1.exe and ccplus.exe files do exist in the package folders !)
). Microsoft Visual Studio 2005 is even worse. i don't remember the errors but it's worse anyway.
what should i do ?
Both dev-cpp and msvc2005 have options for creating a windows application (gui, may be the specific option referred to by dev-cpp) so you should make sure you create the right project type.
Most compilers are smart enough to recognise a *.c as a c file and *.cpp as c++ but the ide's that interface with them usually have default options set when you create a project which may include what the language used is, regardless of source code file extension. So you also need to be aware that you'll probably need to specify whether you want to compile your project as c or c++ - those 'invalid conversion' errors from dev-cpp are because you are attempting to compile c code as c++. The code::blocks issues look, at first glance, to be configuration problems, too. The msvc errors you allude to are likely, again, a result of incorrect project creation selection; there may also be some unicode issues but, without specific information from you, there's not much point in speculating further about it.
Rather than jumping around from place to place, pick one ide, whichever you find the simplest at present and fiddle around with creating new projects until you are comfortable with the various options available and the results produced. Since you seem to be closest to a result with dev-cpp, it would seem prudent to stick with that at present.