|
The most efficient method here would be to use Microsoft Spy++ to find out the class name of the window, then use FindWindow on the class name instead of window caption.
Just start Spy++, start the target program, and detect it's class name. If you do not know how to use Spy++, refer to it's help files, they are very throughout.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
I tried that, but for the class name I get an long string (Afx:4000...) that seems to vary each time I run it. Am I doing something wrong?
Thanks,
Todd Krzeminski
tkrzeminski@nlxcorp.com
|
|
|
|
|
This type of class name means that the program uses MFC to register a new class for itself always when it is run.
This means that the class name of the window is not an usable option. The other poster suggested using window enumeration callback routine. I find this the best alternative as well. Just get the caption of each window and compare X characters of it to see if there is a match. I remember you saying that certain characters of the window title always remain constant, so this would sound like the best course of action.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
tjkrz wrote:
How can I get a pointer to this window without knowing what the title is going to be?
How about the window's class name?
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
If you can't use the class name, then the best alternative is to use EnumWindows. This will call a function you provide. With each callback you get will need to retrieve the titlebar text and do your own matching. Once you've found the window you can return FALSE to stop the enumeration early.
Hope that helps.
--
Joel Lucsy
|
|
|
|
|
Thanks, I got it working with EnumWindows.
|
|
|
|
|
Hi everyone,
I got myself a copy of Andrei Alexandrescu's Modern C++ Design after hearing a lot of good things about it. The book is on the heavy side though. I never used templates much before, but this book seems to open new vistas for great design.
I read the first chapter last night and was thinking about it the whole day. The topic of discussion being policy classes. Everything seemed fine, but I cannot understand one point:
He states that [B]Make the destructors of the policy classes protected and non-virtual[/B]
However, will this not lead to problems if someone instantiates a derived class through a base class:
Here is a small example, I am sure you guys have seen this millions of times. I, however, am a novice. So please advice:
Here is a small pseudo policy and a derived class:
<code>
template <class T>
class SuperBase
{
public:
virtual void OpenSource()
{
std::cout << "In superbase opensource" << std::endl;
}
};
template <class T>
class MyDataSource: public SuperBase<T>
{
public:
MyDataSource()
{
some = new T;
}
void OpenSource()
{
std::cout << "In mydatasource open source" << std::endl;
}
private:
T * some;
protected:
~MyDataSource()
{
std::cout << "In destructor of my source" << std::endl;
delete some;
}
};
Now, in my main program if I do this:
SuperBase<int> * temp = new MyDataSource<int>;
temp->OpenSource();
delete temp;
</code>
This will of course never call the destructor of MyDataSource.
Am I missing a design detail here. Are these templated classes never supposed to be derived from. How can I make sure such heritance is safe (in keeping with the design principle here).
Thanks a bunch.
Xargon
Without struggle, there is no progress
|
|
|
|
|
Well, a golden rule in C++ is that if you have a virtual method in a class, you should also add a virtual destructor. If you've made one method virtual then you have implied that the class may be inherited. And if that's the case, anything but a virtual destructor would be bad design as it will most likely leak.
I think you should add a virtual destructor in the SuperBase class. That will make sure the MyDataSource<T> destructor is called (since MyDataSource<T> inherits from SuperBase).
I haven't read (unfortunately) this book you mention yet, so I'm not really 100% about the terminology. But is this really how a policy class is supposed to work? I thought policy classes were something along the lines of traits in C++ which are mostly static classes relying mainly on type and method names.
--
20 eyes in my head, they're all the same![^]
|
|
|
|
|
I figured out what my mistake was:
- The destructor of the policy class is supposed to be protected, not the derived class. Basically, Andrei breaks from the rule that Inheritance behavior is IS-A. he rather prefers..Inheritance as USES. I would probably disagree with him on that.
Just to be clear, let me create a small example:
Recently, I had to write a small module and that reads a binary file generated by some system, extract the data, and put it in an SQL server database. I had to do it in C++. The trick is to try and see which method suits the best for the particular design:
- I wanted the design to be a bit generic, so people could expand on it. So I had a base class like so (for simplicity let us say it has only one method for writing to database called WriteExperiment():
class DataSourceBase
{
public:
DataSourceBase();
virtual ~DataSourceBase();
virtual bool OpenSource(std::string & connectionStr);
virtual bool CloseSource();
virtual bool WriteExperiment(int data);
};
Now, for my need I inherit from this class:
class SqlServerSource: public DataSourceBase
....
// You know the drill...
Then I have a writer class basically which takes a reference to a DataSourceBase object and polymorphism does the rest.
With the template based method, I would do the same as:
class SqlServerSource
{
public:
SqlServerSource()
{}
bool OpenSource(std::string & connectionStr){}
bool CloseSource() {return true}
bool IsOpen()
{
return true;
}
protected:
~SqlServerSource(){}
};
template <class DataSource>
class WriteExperimentPolicy
{
public:
WriteExperimentPolicy() {}
void SetDataSource(DataSource * source)
{
m_pDataSource = source;
}
bool WriteExperiment(int val)
{
// Do something here
return true;
}
private:
DataSource * m_pDataSource;
protected:
~WriteExperimentPolicy();
};
// My class which uses both of them
template <class DataSource, class WritePolicy>
class MySource: public DataSource, WritePolicy
{
public:
MySource()
{}
void Test()
{
if (this->IsOpen())
this->WriteExperiment(1);
}
};
// In the main application:
typedef MySource<SqlServerSource, WriteExperimentPolicy<SqlServerSource> >Source;
int main()
{
Source temp;
temp.Test();
return 0;
}
I have just read the first chapter, but it looks like I can learn a lot from this book. I would never even think of doing this before. I was very hesitant with templates and never used it much. I am a very novice programmer and got miles to go still 
Pankaj
Without struggle, there is no progress
|
|
|
|
|
pankajdaga wrote:
Am I missing a design detail here. Are these templated classes never supposed to be derived from. How can I make sure such heritance is safe (in keeping with the design principle here).
You're exacly correct, but see section 1.7 "Destructors of policy classes" for Alexandrescu's solution (so make policy classes destructors non-virtual and protected.
[edit]
Just to add a little more info - you can sucessfully create the object using new, but the subsequent call to delete will be a compiler error, because the base class destructor is protected.
[/edit]
If you can keep you head when all about you
Are losing theirs and blaming it on you;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts you aim;
Yours is the Earth and everything that's in it.
Rudyard Kipling
|
|
|
|
|
Yeah, I had made the mistake here:
I had made the dtor of the derived class protected. My bad!
This is a great book! I have learnt so much from just the first chapter. It is heavy reading though, so I am continuing at a slow pace...making sure I absorb most of it.
Pankaj
Without struggle, there is no progress
|
|
|
|
|
Hello,
Is there a Windows API that will tell me whether hyperthreading is enabled or not on a PC?
|
|
|
|
|
Are you referring to identifying a hyperthread supported CPU? Check out CodeProject code section.
http://www.codeproject.com/system/camel.asp
Kuphryn
|
|
|
|
|
No, I know it is a hyperthread supported CPU - I just want to know whether it is activated or not.
|
|
|
|
|
Have you gone through this tutorial, specifically lesson 8?
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
I have now! Thanks very much.
|
|
|
|
|
Hi,
I'm trying to create a library from original source code. The code is not mine and only includes .c, .h, .def files. Hence, no simple project file to load. I create my own empty project and build the library. It seems to do it fine (with a few warnings). However, I create another app which actually uses the newly created library. I get errors when I try to use it. It gives me LNK2001 unresolved external symbol _imp_my_thing. I search for my_thing in the source code of the library and find it is a structure defined as, "extern struct my_thing my_thing;". Do I need to include the .def files when I create the library? Or does the code need to be modified. Thanks.
|
|
|
|
|
Have you tried putting:
#ifdef __cplusplus
extern "C" {
< your function declarations here >
}
#endif
This will keep the compiler from mangling the names. Also, make sure that the library is in the list of libraries to include in the link. (Bet you have done this!)
Larry J. Siddens
|
|
|
|
|
Anonymous wrote:
Or does the code need to be modified
Short Answer. Yes
Longer Answer. The source code for the library expects to be linked with another library that has defined a struct my_thing. If your use of the library does not use any part of this struct, then I would comment out the extern definition, comment out the parts that use it and then rebuild it. Your app should then link okay.
Chris Meech
It's much easier to get rich telling people what they want to hear. Chistopher Duncan
I can't help getting older, but I refuse to grow up. Roger Wright
I've been meaning to change my sig. Thanks! Alvaro Mendez
We're more like a hobbiest in a Home Depot drooling at all the shiny power tools, rather than a craftsman that makes the chair to an exacting level of comfort by measuring the customer's butt. Marc Clifton
|
|
|
|
|
 Hi, i'm currently realy busy on a Vb.Net project and was wondering if anybody could produce a simple multithreaded program for me in visual c++. If u could e-mail me your e-mail address, I will send u the required flow diagram for the structure of the program, would really appreciate it..Thanks again, stevie.
stevie Murdock
|
|
|
|
|
lol, where the hell do u think u are!?
in a supermarket??
do ur homework urself and go away!
Don't try it, just do it! 
|
|
|
|
|
|
hah!
You are looking directly at solutions and you do not even realize it.
Sad.
Kuphryn
|
|
|
|
|
|
Cash, in small, unmarked bills. Payment in advance. No refunds. 
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
