The MSDN docs say "The path can be specified as a Unicode string or a PIDL" for the BFFM_SETSELECTION message (inside a BrowseCallbackProc function after calling SHBrowseForFolder), but when I send a Unicode string instead of an ansi one it fails. Is the documentation wrong?
The Microsoft documentation has a couple of minor errors I should point out in case you try to program SHBrowseForFolder in C. The documentation says to pass the string for BFFM_SETOKTEXT in WPARAM; actually, it's LPARAM. It also says that BFFM_SETSELECTION requires a Unicode string, but BFFM_SETSELECTION is available in both A and W flavors, so you can use LPCTSTR.
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
-- modified at 9:00 Sunday 8th January, 2006
Last Visit: 31-Dec-99 19:00 Last Update: 30-Nov-23 7:17