|
hey Joaquin,
lol, well actually... i'm not writing a winsock class, and if i have to read 878 pages first to learn OOP it wont be for this year lol.
I'm actually writing a class that will serve as a chat engine for www.spinchat.com. I always go to this chat and it's easy to write Bots for it because it works with non-encrypted text commands
I already started writing two bots but never used classes and that took too long so now i'm trying to write a class i can just reuse everytime.
I don't know if i'll be posting it on the Codeproject because others also made bots but in Delphi and VB so i wanted to do it better but if i post the class then they'll be able to write one as easily as in VB (probably even easier) so... i'm not sure, maybe i'll leave a few 'special' functions out so i still have something to call my own . Anyways, i'm sure i'll be writing more articles and contribute to the codeproject throughout my findings.
Greets - K.
Kuniva
--------------------------------------------
God gave man a penis and a brain but not enough blood to make both of 'em work at the same time.
|
|
|
|
|
hi,
....I am addicted to using SendMessage instead of using functions.I mean suppose I have to paint the screen in custom color if Left button double click,
earlier- I used to put a function for painting in OnLBDblClk
now-I use SendMessage(MYM_PAINT,...) for that just as in his message related article.
This has become a habit for every action.
Is it BAD?
Please help by telling me good and bad techniques.
Waiting.
|
|
|
|
|
Bad? Well it depends on your definition of bad. If it works, it works...
Wasteful? Very.
It takes a fair amount of overhead to send a message to a window. Much easier just to invoke a function. Functions are a LOT more versatile too.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
In the example you gave I think you would be better off to set some state variables that tell your program the screen needs to be a custom color, then Invalidate the window in question and place logic in your OnPaint handler to deal with this.
Personally, I don't see the use of SendMessage as all that bad because a huge number of the MFC methods are just wrappers around SendMessage calls anyway. I am not familiar with the article you are referring to but I have written a fairly wide variety of apps and I have never required a user defined message code that I can recall. This is just my opinion though.
|
|
|
|
|
Hi,
Just a little question (not very important... just to know ;o))) :
I compiled the following code in VC++ (no MFC) :
// Test.cpp
#include <windows.h>
int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
MessageBox(NULL, "Hello World", "Hello", MB_OK);
return 0;
}
And the EXE size is 36 ko ! I often saw EXE's of 5-10 ko, is there a way to reduce the size ?? (I mean, without compressing the EXE with UPX or other executable packers..).
|
|
|
|
|
Ooops... #include <windows.h> of course...
|
|
|
|
|
Nice morning exercise to start the day!
Let me outline my steps:- Take out the C runtime library (idea from ATL):
The compiler by default will link in CRT startup code before actually calling your entry point function. So the first step (and the biggest) step is to remove those CRT stuff since you are just using Win32 API. Borrowing idea from ATL's WinMainCRTStartup I put something like this:
void WinMainCRTStartup(void)<br>{<br> WinMain(GetModuleHandle(NULL), NULL, NULL, 0);<br> return;<br>} This takes 20K out of the exe and it is down to 16K. - I tried a few things and I think the compiler just won't reduce the size further. It always give you 3 segments and stuff. So I thought of UPX, the exe compression tool (I know I cheated a bit here, but I don't know assembly! ). I used it to compress my exe and boom... it is down to 2560 bytes!
- Without resorting to assembly (I don't know the PE format too much :p ), I opened up the original exe in binary mode and I noticed a lot of blanks (to fill up the segments I suppose). So I thought, "if I could make the segments more blank then I may be able to get more compression out of this". I notice that I am calling 2 functions from Win32 API, killing 1 of them should make the import table more compressible. Since I am not interested in the module handle, I make that NULL:
WinMain(NULL, NULL, NULL, 0); Unfortunately that didn't work, UPX still compressed it to 2560 bytes. - My final step is to realize that I am doing a 2-step function call to get to the
MessageBox . So I killed my WinMain and make my entry point function call MessageBox directly:
void WinMainCRTStartup(void)<br>{<br> MessageBox(NULL, "Hello World","Hello", MB_OK);<br>} Now, that didn't do much in terms of the compiler, it still gave me 16K, but UPX made it down to 2048 bytes! I guess my code segment is more compressible now.
To sum up, here is a little table for you:
Before UPX After UPX
Plain old WinMain() 36384 12288
Minus CRT 16384 2560
Minus GetModuleHandle() 16384 2560
Direct call 16384 2048
So there you have it, my morning exercise.
I would be interested to know what the assembly guys can do here!
|
|
|
|
|
There's an MSJ Under the Hood article by by Matt Pietrek that talks about some of this stuff too - search the MSDN for 'TINYCRT'.
Also, you might want to look at this (also by Matt Pietrek) for a more general overview of how compiler and linker settings affect app size.
|
|
|
|
|
std::getline(cin, somestring, '\n' ) seems to work as cin>>somestring with my Visual C++ 6.0. It sees whitespace as delimiter so i cant get multiword sentence from cin ... Whats wrong?
|
|
|
|
|
std::getline(cin,somestring,'\n') shouldn't stop on whitespace. My guess is that you are misinterpreting the behavior of your program. Could you please post a snippet of code where this anomaly shows?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
in this member function...
void PolishNotation::GetExpression()
{
cout<<"Insert Expression: "<
|
|
|
|
|
comments for my previous post: m_strExpression is std::string of course...
An idea came across my mind: Maybe its somehow involved with this
Bug fix? But it seems highly unlikely...
Hannes
|
|
|
|
|
I don't think it has to do with that bug --the manifestations are different.
I don't know. It beats me. It's so simple I cannot figure out what more to test. Are you 100% sure m_strExpression doesn't contain whitespace although you've typed it in? How are you checking the actual value of this variable?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Hi,
when the child window is moved over the parent window,what message does the parent window receives?
Neha
|
|
|
|
|
That's a tough one!
Here's a tip though - if you have Visual Studio, you'll have a utility called Spy++ - you can use it to hook and display selected messages for a window, in this case the parent. (Use the Window Finder and select Messages).
Once you get Spy++ displaying the messages for the parent, drag your child window over it. You'll find all sorts of interesting stuff.
|
|
|
|
|
The parent window may receive a WM_PAINT message if moving the child window unconvered part of the parent. Otherwise, I don't think the parent window will receive any message.
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
I want to use a CPaintDC as public member,I want to put CPaintDC of OnPaint into this member,but there is no '=' operator for this class,is there any way for doing this?
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here." Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
Mazdak wrote:
I want to use a CPaintDC as public member ...
Not a good idea - CPaintDC is designed to be constructed and destroyed within the context of an OnPaint handler.
If you want a static device context for your window, declare a window class that has the CS_OWNDC flag set, then use GetDC to initialize the member CDC or hDC. However, you should still only draw to this DC within the context of a WM_PAINT message.
|
|
|
|
|
It is also important to remember that if you go this route, that you must call ValidateRect or ValidateRgn if you decide to go this route. If you don't, the invalid region for the window that is receiving the paint message will not be erased, and this window will continue to receive these paint messages even when there is no need to paint, kind of like an infinite loop of paints.
Also, when you use GetDC, you will be given a DC that has the ability to paint on the entire window, depending on the type of painting that you are doing, this may cause flickering. That is why if you use this technique, again, you should call GetInvalidRgn on the window, before you call ValidateRect or ValidateRgn.
Usually you would use this technique if you want to perform painting outside of the paint handler.
Even if you use the CS_OWNDC style in your window class, when you call BeginPaint, it will return the same DC that is cached by your window. I believe that this is your best route, to making the best looking window.
Remember, there are only so many resources available on the system, and you should weigh the circumstances of your window design carefully before you try to cache window DC's. You do not need to worry about this so much on the NT based systems, however the 9x systems have a limited number of concurrent DC's that can be created.
I know alot about the internals of the Windows paint architecture, if you need any more information, please let me know.
|
|
|
|
|
Can you tell a green field,
From a cold, steel rail,
A smile from a veil,
Do you think you can tell?
Did they get you to trade,
Your heroes for ghosts,
Hot ashes for trees,
Hot air for a cool breeze,
Cold comfort for change,
Did you exchange,
A walk-on part in the war,
For a lead role in a cage?
One of my favorite songs!
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Use CClientDC outside of OnPaint. You would be better to make a bitmap a public member and just select it into a DC when you need it.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
|
|
|
|
|
Christian Graus wrote:
to make a bitmap a public member
You mean I should paint into this "bitmap"?
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here." Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
Yes, you need to select it into a DC, but it's the bitmap, and not the DC, that should be a public member.
If you don't select a bitmap into a DC then not much is going to happen, unless it's a PaintDC or ClientDC (which has one already).
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
|
|
|
|
|
I'm programing in C language.
I'd like to use the wsprintf function with a LPTSTR variable.
here my code:
void GetDescription (LPTSTR Description)
{
char TypeRes[100];
char Resources[100];
lstrcpy (TypeRes, "Bitmap");
lstrcpy (Resource, "file.bmp");
Description=wsprintf (Description, "<%s : %s>", TypeRes, Resources);
}
It doesn't work! The variable Description is empty or invalid. But I have to use LPTSTR not char[xxx], otherwise, my program is very slow and I get a memory error.
Help me!!!!!!
Appstmd
|
|
|
|
|
If you use wsprintf() I guess you have defined UNICODE and _UNICODE, in that case you can not ude char, but should instead use wchar_t.
Description=wsprintf() fails, wsprintf returns the number of characters the function put in to a string, not the string itself, so you should use something like int result = wsprintf (Description, "<%s : %s>", TypeRes, Resources);.
Make sure that Description are large enough to contain the text you pun into it with wsprintf()
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|