|
sawerr wrote: Com is a part of win32.right?
No. COM was first called ActiveX and ActiveX didn't even exist when Win32 came along.
sawerr wrote: In fact i don't sure what are the steps for learning win32.
First, get used to pain. Programming Win32 style is a lot harder than MFC, which is itself a lot harder than using C#/Winforms. WPF brings something new to the table, I think it's harder than C#/Winforms 
But, if you want to use Win32, by 'Programming Windows' by Charles Petzold. There's not other book half as good.
sawerr wrote: I decided that first learning com(I have 3 books) and then win32(ı have 2 books).
Unless your terminology is strange, that's a weird order. COM is a way of creating dlls that expose an interface which is mainly useful for being able to call stuff without having any idea where it is on the file system ( otherwise, you could just use plain old dlls ), and for exposing an interface through your app ( as Office does, for example ).
What are you trying to learn exactly, and what is your background ?
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Thanks Christian
I start programming with c and after that i learned c# and.Net well.I see that they are not enough for me for writing low level(i mean orginial) applications.So I started to learn c++ and STL and I finished them.
In fact i know both com and win32 generally.
I am member of safari bookshelf and in my bookshelf there are 5 books and i can not decide to order of reading these books.
1-)COM+ Programming: A Practical Guide Using Visual C++ and ATL
2-)Microsoft Windows 2000 API SuperBible
3-)Win32 System Services: The Heart of Windows® 98 and Windows® 2000
4-)Applying COM+
5-)COM and .NET Component Services
So i want your advices to learning win32-com-mfc with visual c++.If you tell me order of reading these books will very helpful.An other advices will be greatly appreciated
Thanks again
|
|
|
|
|
sawerr wrote: I start programming with c and after that i learned c# and.Net
Wow - C to C# is a big leap. So C# was your first OOP ?
sawerr wrote: I see that they are not enough for me for writing low level(i mean orginial) applications.
I totally disagree. C is indeed hard, but if you learn WinAPI programming instead of MFC, you're basically learning windows in C, that's where it comes from. But, I write 'original' programs in C# that interact with digital cameras, do image processing, video capture, etc.
sawerr wrote: So I started to learn c++ and STL and I finished them.
LOL - I doubt that. No-one finishes learning any language, especially C++ and STL.
sawerr wrote: COM+ Programming: A Practical Guide Using Visual C++ and ATL
COM+ is a superset of COM. That means any COM+ book will teach you more than you need to know to use COM.
sawerr wrote: COM and .NET Component Services
This book is probably mostly about interop.
sawerr wrote: If you tell me order of reading these books will very helpful.An other advices will be greatly appreciated
I would forget Win32 and go straight to MFC. For this, I can't even remember the books I used. I do know the best COM book I read, the one that made me understand it all, was called 'Building lightweight components with ATL' by Jonathan Bates.
I still don't get why you feel the need to learn COM, but if you do, I'd certainly recommend learning MFC first.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: I would forget Win32 and go straight to MFC.
I wouldn't say that, starting with Win32 allows you to gain a better understanding of exactly what the code is doing. I feel MFC takes the fun away, sure it makes things easier and faster, but all the work is already done for you.
I started out with BASIC on a Vic20, moved on to C now going through C++ (after a long break).
Regarding books, personaly I wouldn't bother. The internet already has all the books, tutorials, forums and examples you will ever need.
|
|
|
|
|
Sorry to disagree with almost everything you said, but...
waldermort wrote: starting with Win32 allows you to gain a better understanding of exactly what the code is doing
Yeah, perhaps, but Win32 is complex enough, I think it's a better approach to learn MFC, THEN go on to learn Win32 so you can appreciate what MFC is doing for you. Just like I'd teach beginners to use std::string before showing them how to work with char *
waldermort wrote: I feel MFC takes the fun away
I tend to agree, but coding is not about fun, it's about getting the job done. That's why I use C# a lot, and Win32 almost never.
waldermort wrote: I started out with BASIC on a Vic20, moved on to C now going through C++ (after a long break).
I started with AppleSoft BASIC, went to Blitz Basic on the Amiga, and then C++ MFC, followed by Win32, followed by C, with some Python in there. That's not counting C#, VB.NET ( yuck), VB script ( double yuck ) et al.
waldermort wrote: Regarding books, personaly I wouldn't bother. The internet already has all the books, tutorials, forums and examples you will ever need.
I totally disagree. The web is a huge collection of disjointed one off articles of various quality. Sites like CP are invaluable, but so is having a good core book or two to work through, especially when starting a new language/framework. I live online, I use CP a lot, I still buy a lot of books.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: Yeah, perhaps, but Win32 is complex enough, I think it's a better approach to learn MFC, THEN go on to learn Win32 so you can appreciate what MFC is doing for you. Just like I'd teach beginners to use std::string before showing them how to work with char *
Each to their own I suppose, I have a habit of always jumping into the deep end otherwise I become lazy.
Christian Graus wrote: I totally disagree. The web is a huge collection of disjointed one off articles of various quality. Sites like CP are invaluable, but so is having a good core book or two to work through, especially when starting a new language/framework. I live online, I use CP a lot, I still buy a lot of books.
Usually, I will go to a bookshop to find something suitable, then scoure the net for it. You are sure to find an E-book out there. If feel if you are goint to spend a fortune on books, you might aswell pay for an evening class or private tutor.
|
|
|
|
|
I would disagree with you that learning Win32 is harder C#/Winforms. I agree that MFC is a PITA and makes Windows UI programming more difficult than need be. You end up getting HWNDs and calling thin wrappers around the Win32 calls anyway. In fact, learning the Win32 API is vital to the fundamentals in Windows UI programming and getting one's head around this ensures successful use of MFC, C#/Winforms, or whatever framework that Microsoft may come up with next. I see many programmers who cannot write custom controls or extend the Winforms controls to implement missing features because they are bound by this framework and don't have the fundamentals down. These frameworks wrap the Win32 API anyway, so if you really want to be a top-level Windows UI developer I suggest learning the Win32 API and fundamentals of Windows programming. This will serve you well.
Deus caritas est
|
|
|
|
|
Andy Moore wrote: I would disagree with you that learning Win32 is harder C#/Winforms
Wow - I'd say that's a pretty strong allegation. I doubt many people would agree.
Andy Moore wrote: In fact, learning the Win32 API is vital to the fundamentals in Windows UI programming and getting one's head around this ensures successful use of MFC, C#/Winforms, or whatever framework that Microsoft may come up with next.
This is absolutely true. And, as you said, MFC really is just Win32 wrappers, and that's half my point. MFC is easier in a lot of ways, and if you do MFC for a while, Win32 is easy to learn, you learned half of it without ever realising it.
Andy Moore wrote: These frameworks wrap the Win32 API anyway
Yes, this is still true today, until WPF takes over
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Hi,
I was wondering if anybody knows if there is some gui library that allows you to create freshly looking menus and controls which resemble windows vista (looking fresh and clean) and that would run on XP and Windows 2000?
I also like the GUI of real player 10 - this would also be good.
The normal standard issue MFC menus and controls are kind of outdated for the app that I'm working on.
Any idea would be greatly appreciated.
Thanks.
|
|
|
|
|
Im not sure but i think i see an article in codeproject about vista style menu
|
|
|
|
|
Hi.
Right, I have a WIN32 console application. I would like to know how to change the background from black to white. So that I can have black text on a white background.
I know how to alter individual pieces if text foreground and background colour, but I would like to be able to alter the entire console window foreground and background colour.
Many regards.
James.
|
|
|
|
|
just run your console app, right click the title bar to open the proerties dialog and set it from there. Remember to click yes when it prompts you to save for all future windows.
|
|
|
|
|
Sorry, I was not clear, I meant programmatically, at the console initialisation stage.
James.
|
|
|
|
|
FillConsoleOutputAttribute
|
|
|
|
|
Thank you very much for the response.
The function is indeed useful, however, I would like to know if there is a way to define the console output attributes at creation time, as my application writes an indeterminate number of lines to its output console. I would like to avoid the overhead of having to determine if the next write will be ‘outside’ the currently defined range of cells covered by the last call to function.
Is there a way to specify at console initialisation, for example, the background colour of all console line output ?
James.
|
|
|
|
|
Use FillConsoleOutputAttribute when your program starts to fill the entire console with one colour.
Use SetConsoleTextAttribute to set the current colour used for text-output
these are fully documented in MSDN, I really don't know why people don't read the documentation before asking questions - it would save you a lot of time.
|
|
|
|
|
Thanks again for the response.
I really do not understand your need to be critical of my question whilst at the same time attempting to answer it. Why did you bother if the question is so trivial?. Your answer is not even directed at me, it is a cheap arogant point scroring excercise and very childish. There are people of differing levels of experience and competence that post questions on this forum and it is people like you that most of us in the industry despise. Please feel free to ignore any further questions that I might post, I would rather not have your help.
And, your response does not answer my question - try re-reading it.
James.
|
|
|
|
|
Excuse me, but being overly sensitive and calling people arrogant and childish is what the 'industry' despise. I am suggesting you read the documentation as this is surely the starting point of any programming question. Going by the limited description of your problem I provided an accurate solution which you would also be advised to investigate by reading the relevant MSDN pages. If you still insist that this is 'wrong' then try articulting your question a little more clearly.
|
|
|
|
|
Prior to posting my original question, I had read all the MSDN documentation regarding console functionality. I could not find what I wanted, so I posted the question. If there is anyone that knows if there is a way to set console output to display in a particular colour without having to specify the number of output bytes, ie) to be able to avoid the overhead of having to keep track of the number of bytes written so far? If there is not, then so be it, but if there is, then I would very much like some pointers.
James.
|
|
|
|
|
James,
I really do believe the FillConsoleOutputAttribute will solve your problem - and do shouldn't need to know how many characters/bytes have been written. I had assumed you just wanted to fill the entire console buffer with the same colour? You can use FillConsoleOutputAttribute to colour all cell-positions within the console, not just those characters already written (think about how the 'CLS' command might work). So the number of characters to fill = width_of_console * height_of_console. Filling the entire console does not alter the 'cursor position' it just sets the cell-colours.
GetConsoleScreenBufferInfo API will return you information regarding the size of the output-window (in the CONSOLE_SCREEN_BUFFER_INFO::dwSize field). So your number of characters. This is untested code:
HANDLE hConsole = GetStdHandle(STD_OUTPUT_HANDLE);
CONSOLE_SCREEN_BUFFER_INFO csbi;
GetConsoleScreenBufferInfo(hConsole, &csbi);
COORD top = { 0, 0 };
DWORD written;
WORD attr = << colour value here >>
FillConsoleOutputAttribute(hConsole, attr, csbi.dwSize.x * csbi.dwSize.y, top,
&written);
Documentation for FillConsoleOutputAttribute states: "If the number of character cells whose attributes are to be set extends beyond the end of the specified row in the screen buffer, the cells are written up to the end of the screen buffer". So you could in fact omit the GetConsoleScreenBufferInfo and just specify a "big" number for the number-of-characters. (i.e. 2^31).
Hope this was of some help, and sorry that we got off on the wrong foot.
regards,
James
|
|
|
|
|
James
Thank you for the reply.
I do not want an argument and I do appreciate the response, dealing with WIN32 is a nightmare and I really do value your help. I do applogise for calling you arrogant and childish, I just sometimes find it frustrating on this web-site because there are so many people that post questions that are clearly homework and I can understand experienced members like yourself that get tired of the endless ill thought through quick fix demands from those that do want to exhaust other channels before posting a help me help question.
I will look into what you have advised and I appreciate the help.
Best regards.
James.
As a point of interest, I cannot believe that you cannot create a console with a default foreground/background output attribute.
|
|
|
|
|
Sorry..that should have been "...from those that do NOT want to exhaust..."
Bit of a typo problem there!
|
|
|
|
|
Why does it have to be so complex? I'm still trying to convert my code but I have ran into a brick wall. I'm reading UTF16 encoded strings from a byte array, most of these strings are Chinese simplified. So for a MBCS I use this
WideCharToMultiByte(936/* GB_2312 */,0,(unsigned short *)data,length/2,text,length+1,NULL,NULL);
The data member there is a pointer within this array. This works, it gives me a string of Multibyte characters. Here is the first character: 0xB0 0xB6. Now, for a unicode build, I should be able to read directly from the array: 0x73ED. According to my charmap utility, this is the correct value for this character. But all I see is "?". Ok, try converting the first multibyte result back to wide:
MultiByteToWideChar(CP_ACP,0,text,length,lpW,length+1);
Exactly the same result: 0x73ED. But I am still not seeing it. Lets try the other, simpler, multi to wide function:
mbstowcs(lpW,text,length);
This time the output is a little different: 0x00B0 0x00E0, and I can see it.
Can anybody explain what is going on here?
|
|
|
|
|
Read the WideCharToMultiByte() docs closer, you'll see that there's a fall back character, which defaults to '?'. This character is inserted in the MBCS string when there is no character in the given codepage that matches the Unicode code point.
I can't tell from your post if WideCharToMultiByte() is doing the conversion right. What could be happening is the program you're using to inspect the strings is doing its own WideCharToMultiByte() and the fallback behavior is happening there, which leads to '?' in the display.
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
I figured out that MultiByteToWideChar() was infact doing the correct convertion. I was seeing the '?' in the debugger aswell as the console. The strange thing is that when I added <tchar.h> to the file, I could see the correct character in the debugger (tchar was already included in the stdafx). The thing that was throwing me off was the inability to see the unicode in the console. I tried variations of wcout and wprintf yet they showed nothing.
I have just stripped out all the tchar routines I added to the code, I am instead going to create overide functions similar to the A's and W's in the stl.
-- modified at 4:09 Sunday 27th August, 2006
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
