|
hi,
i've got a problem with getwindowtext. i've spent at least an hour trying to figure out why this won't work. (sad, huh?) i have this code:
BOOL CALLBACK EnumWindowsProc(HWND hwnd, LPARAM lParam)
{
LPSTR title = "";
CString thetitle = "";
GetWindowText(hwnd, title, 100);
thetitle = (CString) title;
AfxMessageBox(thetitle);
if(thetitle == "...") {
...
}
return TRUE;
}
onSomeButtonClick...() {
if(!EnumWindows((WNDENUMPROC) EnumWindowsProc, 0)) {
...
}
}for some reason, thetitle is always blank. can someone tell me why this is happening? any tips for fixing this would help.
thanks.
-- modified at 21:14 Wednesday 24th May, 2006
|
|
|
|
|
Try
<br />
char title[100];<br />
GetWindowText(hwnd, title, 100);<br />
Regards
Anil
|
|
|
|
|
it worked! thanks a lot.
1 more question... how do you put the text in that font? 
|
|
|
|
|
Sorry did not get your question
Regards
Anil
|
|
|
|
|
Forget about it then. Doesn't matter.
Thanks.
|
|
|
|
|
Sam Kline wrote: it worked! thanks a lot.
1 more question... how do you put the text in that font?
Look down where the smileys are. Just above them there is a section called
Formatting: B I U S small BIG...
Hope you saw it. Now select any text and just click on those items. Now your selected text will be wrapped within html tags.
Thats it. Hope this is what you meant. 
Nibu thomas
A Developer
Programming tips[^] My site[^]
|
|
|
|
|
|
OK, I have recently been looking into putting and end to my singleton woes once and for all by creating a singleton base class from which any class that needs to be a singleon can simply inherit and hey presto its a singleton.
Now I refer you to the article http://www.codeproject.com/cpp/singleton.asp (probably the best article I have seen on the matter).
Having seen another implementation that makes use of creation policies I have decided that this is the way to go and provides the greatest flexibility while still being a single class. However, from my experimemts with this design I have noticed that in order for derived classes to be true singletons, their constructors must be declared private (or rather not public) otherwise an instance of the derived class may be declared. Im guessing this goes without saying and there is no way around it but I was hoping that maybe the fact the singleton base class's constructors were private might have prevented this.
Secondly, it seems that unless the class used as the singleton base class's creation policy is declared as a friend in the derived class, the code does not compile saying that the creation policy cannot access the private constructor. Now, although this isnt the end of the world its the final niggle in an otherwise perfect design.
So, hopefully you follow thats not too hard to follow. My question is,does anyone know of any ways around these two issues?
Hopefully someone who knows more than me can shed some insight on this.
Thanks for your time.
Louis Clayton
|
|
|
|
|
Louis Clayton wrote: I have noticed that in order for derived classes to be true singletons, their constructors must be declared private (or rather not public) otherwise an instance of the derived class may be declared.
Correct.
Louis Clayton wrote: I was hoping that maybe the fact the singleton base class's constructors were private might have prevented this.
If a class has only private constructors, you can't inherit from it. To make a base class implement a singleton, you'll need to declare the base class constructor to be protected. To prevent a class from being constructed by anyone, you'll have to make the constructor either protected or private, and put code in the constructor to enforce the singleton condition.
Louis Clayton wrote: it seems that unless the class used as the singleton base class's creation policy is declared as a friend in the derived class, the code does not compile saying that the creation policy cannot access the private constructor.
Correct. This is one of the reasons I don't like creation policies, they have a tendency to make the code "unclean". However, I have seen some really neat policy setups that are classes given as template parameters, the advantage being that friend declarations are sometimes unnecessary. Have a look at the book Modern C++ Design by Alexandrescu for a very comprehensive and well thought-out singleton design.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
1st off... I'm new to threads so be gentil..
My problem: I am writing an application that opens a socket and reads in image data from a camera. It works... but its slow. I believe this is because the Socket OnReceive is on the same message pump as the UI (onPaint etc) and isnt getting enough attention.
a. I want to move the socket to its own thread so it has its own message pump.
b. The only thing this thread will do is fill a buffer for each frame and then that frame will get processed by the original thread.
What I need:
Some direction... I'm not sure if this is the right approach and I"d like to know if it would even work.
some quick examples would help as well since this will be my first multithreaded application.
thank you in advance!!
-- modified at 16:10 Wednesday 24th May, 2006
|
|
|
|
|
SPowers wrote: a. I want to move the socket to its own thread so it has its own message pump.
See here and here.
"The largest fire starts but with the smallest spark." - David Crow
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
That answers a lot... I'm still a little confused how I can write to a buffer within a thread and have another thread read from it.
Do I keep a pointer to the buffer within both threads and only read from the buffer when i pass a message from the socket thread saying that it is ready to be read?
|
|
|
|
|
This sounds like the reader/writer problem.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
what is the reader/writer problem?
Is my assumption correct?
|
|
|
|
|
SPowers wrote: what is the reader/writer problem?
See here.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
Ok that makes sense....
So I should plan it like this:
Databuffers:
buffer A: w/mutex
holds image data for frame X
buffer B: w/mutex
holds image data for frame y
x & y are concurrent image frames
Thread 1: main prgrm (reading and displaying data from buffer)
will hold pointers to buffer A & B
Thread 2: Socket exists on this thread and will handle sending and receiving data from socket as well as writing data to the data buffers
will hold pointers to buffer A & B
I'll have to put a mutex on the shared buffers so that they dont access it concurrently. And the mutex permissions will switch between the two buffers so that Thread2 can write constantly and Thread1 can read constantly.
Sound like a plan or did I miss the whole point completely?
|
|
|
|
|
Quick question:
Will reading memory that is currently being written cause an error or will it simply cause a versioning problem.
I ask this only because whenever I'm ready to write a frame I just want to dump the buffer into an image and I dont really care much about any versioning concerns.
|
|
|
|
|
It means that a frame could contain half of one image and half of another...
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
That would definately not be a problem (knock on wood). If it is I could always implement a double buffer with mutexes.
I still havnt really gotten an answer about the shared memory. Since I'm new to threads my guess would be that each thread would have a pointer to the same piece of memory. Is that correct?
|
|
|
|
|
SPowers wrote: each thread would have a pointer to the same piece of memory. Is that correct?
Yes, that would work. Each thread shares the same address space, so any thread can access any memory that the application owns.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I have one more question (I think)
http://flounder.com/detach.htm#Sockets shows me how to detach the socket and assign it to a thread.
How do I use the Message Pump within the thread to catch the onReceive()/onSend() Messages
-- modified at 14:45 Thursday 25th May, 2006
|
|
|
|
|
Sorry, can't help you there. I've never used MFC sockets - I always use the raw Win32 versions.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
The help files recommend that user messages be defined in the range WM_USER to 0x7fff, but opening the Resource Symbols dialog to create a new ID and letting it choose the value seems to work fine. Does anyone know if there is anything wrong with this?
Best Regards
Cliff Hatch
-- modified at 14:42 Wednesday 24th May, 2006
|
|
|
|
|
Cliff Hatch wrote: The help files recommend that user messages be defined in the range WM_USER to 0x7fff...
It should be WM_APP.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
Depends on the usage. If you are defining a message that will only be used within the application, then use WM_APP. If the message is for a control that could be used in other apps the use WM_USER. If it is a message that is used to communicate between different modules then use ::RegisterWindowMessage().
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
