|
You can consider using SendInput() or keybd_event() function.
|
|
|
|
|
This function can used if only that the window be the first windows.
I want it behind.
|
|
|
|
|
So, you could use PostMessage as you rightly indicated in your original query. Did you try my suggestion of finding out the messages posted with spy++?
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Then I think you can proceed with what Rajesh has suggested. Use Spy++.
|
|
|
|
|
HI,
I have a CString csPoints=_T("122/23/45/90");
how can i split the above string and need to get the numeric values from the above string..
|
|
|
|
|
kumar sanghvi wrote: have a CString csPoints=_T("122/23/45/90");
how can i split the above string and need to get the numeric values from the above string..
You might use AfxExtractSubstring()[^].
CString has three methods - Mid[^], Right[^], and Left[^]. You may use these functions. Sorry, brain fart. 
And for converting a string to a number, you could use something like _ttoi[^]
“Follow your bliss.” – Joseph Campbell
modified on Wednesday, December 23, 2009 1:06 AM
|
|
|
|
|
Good finding 
Величие не Бога может быть недооценена.
|
|
|
|
|
Well thank you.
But you've selected the "rant" icon (for your message type), which should be used while you're angry about or ranting about something.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
|
Command line error D8016 : '/MTd' and '/clr' command-line options are incompatible
I got this error when i change my Common RUntimesupoort to \clr.
Because i want this option told by some article to use WPF and C#dll in my project.
How can i avoid this error?
I have coonvert vc6.0 to VC++2008.
Anu
|
|
|
|
|
|
I've got a problem trying to define / restrict function accessibility in C++ classes. I'm using the VS2008 compiler, since that does make a difference -- there's a solution using a friend helper class that worked prior to VS2005 but doesn't any more since MS fixed a bunch of conformity error in the later compilers.
I have a base class, an asynchronous callback coming from the OS, and a derived class. The async callback needs to manipulate some of the private variables in the base class. The derived class must NOT be allowed to manipulate those variables and, as such, cannot be allowed to call the function that does so.
My question is how do I modify the following code snippets to do what I want. Don't worry about re-entrancy issues with the callback - that's been removed for the sake of clarity.
baseclass.h
class BaseClass
{
public:
BaseClass ();
void BaseFuncA ();
private:
void CallbackFuncA ();
};baseclass.cpp
void CALLBACK AsyncCallbackFunc (DWORD dwParam)
{
((BaseClass *) dwParam)->CallbackFuncA ();
}
void BaseClass::BaseClass ()
{
}
void BaseClass::CallbackFuncA ()
{
}derivedclass.h
#include "BaseClass.h"
class DrvClass : public BaseClass
{
public:
DrvClass ();
void DerivedFuncA ();
};derivedclass.cpp
void DrvClass::DerivedFuncA ()
{
BaseFuncA ();
}
Thanks!!
Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
How about overriding the function in your derived class, and having the override perform something meaningless, while only the base implementation of the function does the variable manipulation?
|
|
|
|
|
It's more a question of preventing the derived classes from calling the function. I'm looking for a compile-time way to enforce my rule rather than depending on the goodness of the derived class'es writer -- me in this case, so this is something of an academic discussion since I am, by definition, most definitely good. 
The basic issue is how to make the function private with respect to derived classes yet somehow allow a callback who only has a class pointer to call the function. I can't pass a direct pointer to the function as the parameter to the callback because of the nature of the OS function that sets up the callback. It only takes one parameter but can initiate multiple callbacks. I only showed one in my example code to make life simpler.
Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
I see. I wish I knew a way to do that. Good luck. 
|
|
|
|
|
Sounds like the base and derived classes are inverted. The data you want to protect should be in the derived class and not in the base class. Then you could pass in the pointer to an instance of the derived class to the OS function. Depending on your other needs, the base class could implement the do nothing function that accesses the private data it doesn't have. If you need polymorphism, that fuction could be virtual and possibly even abstract.
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
Tim Craig wrote: Sounds like the base and derived classes are inverted.
The base class contains the basic communications logic for talking to a chunk of hardware, things like Initialize, Uninitialize, the low-level details of sending a series of bytes, and the asynchronous callbacks from the hardware detailing hardware state, along with get-type accessors for the derived classes to test the details maintained by the base class. The derived classes contain things like formatting and validating a particular class of message and then synchronously calling the base class to send that message. The base class needs to hide things like the OS handle to the hardware and the event used to synchronize access with the callbacks. I structured it this way because the same basic hardware can operate in different modes (not controlled by the base class), each of which requires a different messaging format but not a different low-level communication scheme.
Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
Maybe an inheritance hierarchy isn't what you need then. Instead of a "is-a" relationship with your base class, you derived classes should have a different base which has a "has-a" relationship with the current base?
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
I'm half asleep, simple-minded, and can't figure out what I'm missing here.
Your program is separate from the OS, but is providing a callback to the OS. I would think that means that you have to be providing the OS with the address of your callback function. It looks like you are putting the callback implementation in the same compilation unit as the class in question. Why doesn't making your callback a private, static member of your class do the job?
|
|
|
|
|
A static member wouldn't have access to the private data of a particular instance of the class.
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
The callback gets a parameter which is a pointer to the particular class instance it is to deal with. Is it no longer allowed to use that pointer to access members of that particular instance?
modified on Wednesday, December 23, 2009 1:40 AM
|
|
|
|
|
True enough. But her main problem is that for whatever reason, good or bad, the derived classes shouldn't be able to see the private parts of the base class. Seems like a poor design to me but then it's not really clear why the requirement. Might just be a matter of documenting it so future developers know the runs on how to use the class and why. That stuff most developers never do. 
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
Tim Craig wrote: But her main problem is that for whatever reason, good or bad, the derived classes shouldn't be able to see the private parts of the base class. Seems like a poor design to me but then it's not really clear why the requirement.
That requirement happens quite often for classes that deal with hardware. The base class implements the hardware interaction and the derived classes add all the validation / formatting / UI error handling / data processing on top of the hardware interaction. It's a hierarchy of adding functionality as you derive.
Think of the base class as an engine and the derived class as a car. The car must contain the functionality of the engine but it doesn't need access to the firing rate of the spark plugs and the gas flow regulator. It just needs a function that says SetOutputPower. Each different car will use the same engine.
I write lots of code that talks to hardware and usually, I don't have this problem. This situation is slightly different because of the way the interaction through the OS happens for this given piece of hardware. A solution is easy -- move those base-class members that the OS-triggered callbacks touch into module-level static variables (outside the base class) in the source file with the base class. I was seeing if there was a way to avoid this since it messes up the data encapsulation of the base class.
Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
I've dealt with a lot of hardware, too. Primarily instrumentation and now robots, that's why I suggested the "has-a", or maybe in this case "uses-a" or "controls-a", relationship with your hardware class. Instead of inheriting from the hardware, the more abstract class simply contains an instance of hardware class or a pointer to "the" instance depending on whether you allow more than one instance of the hardware to exist at a time. This way it only can use the public interface you provide yet still. It isn't a hardware abstraction class but a hardware control class.
In your car class, the car isn't really an engine, it's a collection of parts of which the engine is simply one. The car "has-a" engine. Maybe one of the more important parts but just a part like wheels, tires, windows. In your model the driver would inherit from car while in mine the driver becomes the car controller. The driver doesn't have to know or access all the nitty gritty details of how a car works (that make us MEs drool) but just understand the interface to drive it. Just like the car itself doesn't have to know what kind of engine it has, just the interface to the throttle, fuel system, etc, to get it running and control it.
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
We're taking a different philosophical approach (a pointer to a class versus deriving from a class) to the same domain but it still won't work. Or I can't find a way to finesse the compiler to make it work which is why I asked the question in the first place. Whether the "derived" class inherits from the base class (my way) or is its own class with a pointer to the "base" class (your way), the problem will always exist if I try to put the data items that are modified by the OS callbacks in the "base" class. In order for the callbacks to access the data items in the class, the data must be public. Data hiding dictates that the items are not public since no user / derivative of the class should manipulate them. Hence the conflict.
I've worked around it be making the items static at the module-level in the compilation unit that contains only the "base" class. As I said, I wasn't expecting a solution, but I asked just in case I had missed something.
Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
