C / C++ / MFC

Handle the HDN_BEGINTRACK message by returning TRUE. If you are using MFC, check out OnHeaderBeginTrack(). There are plenty of examples of both of these. "One man's wage rise is another man's price increase." - Harold Wilson "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons "You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

Well,i'm glad to help you.It's my way to solve the problem.In my point,it's exactl solution.Thank you. Quote: //This program calculates a golfers handicap. #include #include using namespace std; int main() { int score, slope; double rating, handicap; string name; int time=1; cout << "This program calculates a golfer's handicap.\n"; cout << "Enter your name: "; cin >> name; cout << "Hello " << name << endl; //Have the user to input their name, score, slope, and handicap. do{ cout << "Please enter your score: "; cin >> score; cout << "Please enter the course slope: "; cin >> slope; cout << "Please enter the course rating: "; cin >> rating; //Calculate the golfers handicap handicap = (score-rating) * 113 / slope ; cout << "Your handicap is " << handicap << endl; time++; }while(time<=10); return 0; }

Try http://www.videolan.org/developers/vlc.html[^].

Thanks!

That is possibly a terrible idea you have 9999 Rect's as you are hoping it's singular process and you can process them on the fly. If you need to come back to them you just wasted a whole pile of time which you will have to repeat. If there is that many entries you would use the bounding box method as discussed by Supercoder and it may be better to bubble sort them or separate them into their own list at the same time while doing the test. At least then for any further processing you don't have to do the long overlap test again. So I am not convinced at all you would process them as per above it really depends what happens next. In vino veritas

So it doesn't TRACE() anything at all when called in CMainFrame::OnMouseMove so it's like it doesn't get the mouse moving at all in MainFrame class... it does trace correct values if I call it in the View class CpositionView::OnMouseMove however I can't find a way to send them from View to MainFrame, although I have included ***View.h and taka them like CpositionView::positionX I get a lot of errors :P

The code you showed above has it spelled as windos.h (missing the last w character). If it is spelled correctly then ensure you have set the path(s) foe the correct include directories. If you are using visual Studio then this should have been done for you at install time.

Visual studio 12 will allow you to compile direct to Windows RT on an ARM processor which can be useful. Personally however I cheat I usually write a UI interface that emulates the the embedded target on the PC or I have an old version of WINE which I have doctored and call Darkside which provides all the basic API interface of windows but runs a very simple concept of a device context and no multitasking. It sort of weird I often have a linux thread kernel pushing into a faked version of Windows UI .... seems all wrong if you think about it. The trick with all these techniques it to have a clear idea of interfaces on your embedded project so you can do the emulations. You can't just start random coding and hot and hope planning is everything.

thank you for you reply. i think the reason is as you pointed out. my enviroment:　windowsXP sp3 + IE8

Both approaches are feasible and valid. Have a look at this page: Limiting Window Resizing - Resizing Controls[^]. Veni, vidi, vici.

In general it may indeed be better to create it on the stack. The reason you'd use new is when you want more control over it's lifetime. For example you can't use the stack if it need to stay "alive" after the function returns (more generally, when it goes out of scope). Steve

Post some code. Not reams of code if you expect an answer, a minimal program that shows your problem. I concede that at times this is easier said than done. Steve

My preferred method is to call CDC::GetSafeHdc() and test the return value for NULL.

I don't know, I started using it almost immediately, while debugging my first network type application.

I have no idea on the mouse manipulation stuff, but you can read stuff from the AVR board if it is visible as COM Port . Where is your problem exactly? Do you have a problem reading the data from the AVR board, or getting the mouse to move? I will never again mention that Dalek Dave was the poster of the One Millionth Lounge Post, nor that it was complete drivel. How to ask a question

Exactly what Richard said above just subclass a static text box and you can use it over and over again. I have a standard code I use to do what you are doing and it also allows you to change the font, text color and background color as well which is all fairly trivial. Let me know if you want to see how to code it as I wont paste that amount of code if you don't need it.

GetClientRect returns the area of the drawable area inside the window. It will usually return something like 0,0,width,height in your rect structure GetWindowRect returns the co-ordinates of the Window itself relative to the upper left of the screen so they will be rather large. If you try to use GetWindowRect co-ordinates to draw on the window they will be way outside the right and bottom and the drawing wont be visible unless you drag the window right up to the top left off screen. You need to use GetClientRect co-ordinates to draw with. Looking at your code I am guessing this line is the problem if you have a position problem dc.BitBlt(137,107,176,50,&memDC,rect.left,rect.top,SRCCOPY); Are you sure that is right?