I just realized the Point class does not provide the = operator. Now that I'm trying to actually use GDI+ in my apps, I'm finding the classes for Rect, RectF, Point, and PointF to be rather peculiar in design.
Also, Rect doesn't provide functions that return the endpoints.
I can't create an Array of Point and copy another Point into one of it's elements (unless it's during initialization). Instead, I have to resort to assigning the X and Y members explicitly into each array element.
I'm not sure if there is some bigger picture I'm missing here or some new highly ultra OOP paradigm I missed the whitepaper on or if this design is just weak and missing some of the useful operators that MFC provided on many of it's classes.
Does anyone have any insight concerning these omissions in some of the more basic classes like Point and Rect? My code just looks rather bloated copying the members individually like this so I thought maybe I'm doing it wrong.
I want to build a win32 console program in VC .Net. I wrote one function in random1.h and random1.cpp, Then, I wrote my main program in SimMCMain.cpp which call this function from random1.h and random1.cpp. It's no problem in VC++ 6.0, but it always has problem when linking in VC.Net. Can anyone give me some suggestion? Thanks
What is SimpleMCMain1? It's not shown anywhere in your code.
Are you creating a CRT application? The LNK2019 linker error might be resolved by changing "Minimize CRT Use in ATL" to "No". Go to Project Properties / Configuration Properties / General. Does that help?
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
The application that I am currently developing is attempting to programmatically control an external application by simulating mouse clicks in it's various windows. I have managed to produce the context menu on the external application by simulating a RH mouse click (using PostMessage's with WM_RBUTTONDOWN / WM_RBUTTONUP). I can also execute an item on the popup menu by positioning the cursor and simulating a LH mouse click (using PostMessage's with WM_LBUTTONDOWN / WM_LBUTTONUP). This all works as expected if there is no other code following it (i.e. my app exits) or there is an AfxMessageBox separating this code and further mouse-click simulations. The failure is that execution of the popup menu item doesn't result in a new window. I get the feeling that the external app is not getting 'time' to receive/react to the simulated clicks until my app exits (Presumably, the AfxMessageBox must also have the same effect - yes ?). I have tried Sleep(10000) after the context menu operation, but this doesn't seem to help. Do I need to (somehow) inform the system that my app doesn't need the remainder of it's current timeslot, thus giving the external app time to "do its stuff". If so, how do I do that ?
Tried SendMessage originally, and couldn't even get the initial stages to work. I have currently got this stuff implemented in InitDialog() of a dialog-based app - and I was in error in my original posting when I said that it only worked when my app exited - I should have said that it only worked once the DoModal() had executed. Is this a clue ??
Assuming you can get the process handle (if your app launched the other app with ::CreateProcess(), for instance), after posting the mouseclick message, try using ::WaitForInputIdle(processHandle, timetowait) like so:
bool bIdle = false;
// wait for five seconds
dwWaitResult = ::WaitForInputIdle(hProcess, 5000);
bIdle = true;
case WAIT_TIMEOUT :
AfxMessageBox("Timed out waiting for idle state.");
case WAIT_FAILED :
// use ::GetLastError() to find error
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
Hi John and VIP ! Thanks for your input - in the meantime, I seem to have solved the (current !) problem - putting my code in InitDialog() seems to be the wrong place. Thinking about it, I suspect that the message loop (pump) is not activated until window initialisation has been completed. I've moved my code into InitInstance() (and actually removed the main window dialog and DoModal() as I currently don't need it !) and everything now works !!! Thanks again ! Perhaps someone can confirm my suspicions about the message loop and InitDialog() - might help someone else in the future !
:\Documents and Settings\nick\Desktop\lalabear project\newporject.cpp(128) : error C2065: 'grahpic_card' : undeclared identifier
C:\Documents and Settings\nick\Desktop\lalabear project\newporject.cpp(128) : error C2065: 'gc_add' : undeclared identifier
C:\Documents and Settings\nick\Desktop\lalabear project\newporject.cpp(128) : error C2182: 'add_new_item' : illegal use of type 'void'
C:\Documents and Settings\nick\Desktop\lalabear project\newporject.cpp(160) : error C2064: term does not evaluate to a function
C:\Documents and Settings\nick\Desktop\lalabear project\newporject.cpp(181) : error C2448: '<unknown>' : function-style initializer appears to be a function definition