|
Hi
I have a worker thread in my project and this thread is waiting the data which is coming from serial port.I want that when a certain data comes from the serial port I will change the keyboard focus from one edit box to another.This data which is coming from serial port will work like TAB button in our keyboards.I know that SetFocus() method is doing that job however when I want to do this in worker thread it is not working.Although I can do many things in worker threads like writing tha data to edit boxes,I can not change visually the keyboard focus from one edit box to another.Is there any body who have an idea about that problem?
Thanks all
|
|
|
|
|
If you're working in MFC then there is a simple rule.
Never do anything in a worker thread that touches the user interface directly in any way. Not even a message box. (Even if it seems to work most of the time)
If you want to change the UI from a worker thread then use PostMessage to tell your main thread to do it and then get the main thread to change the UI in the message handler. You can define your own mesages in the WM_USER + n range for these sort of things and add ON_MESSAGE entries to your message maps to route to your handler.
The reason for this overly strict sounding rule is that MFC blocks the main thread anyway when it does anything UI related even if you call the MFC functions from your worker thread. If the main thread is waiting for the worker to complete but the worker is waiting for MFC to grab the main thread to change the UI nothing will ever happen. This receipe for deadlocks should be avoided by all non masochists 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks for your help.
This solved the problem.
|
|
|
|
|
Matthew Faithfull wrote: You can define your own mesages in the WM_USER + n range for these sort of things
It's better to use WM_APP instead of WM_USER because some of the control classes use WM_USER to define their internal messages (like the TB_* messages). This isn't usually a problem since those messages tend to not be sent to "main window" message queues but it does happen. I speak from experience . Good practice is to use WM_APP instead and avoid the problem.
Judy
|
|
|
|
|
You ought to read this[^] in addition to what Matthew already stated.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Hi All,
I've been out of the application development cycle for quite a while, but now need to touch up again (and quickly). So I was wondering which Visualization and Modelling Tools you would recommend to review, something like StarUML or RationalRose etc. Also which modelling "language" is mainstream these days, still UML, anything else perhaps ?
Thanks
OD
|
|
|
|
|
The silence is deafening 
|
|
|
|
|
Not much has changed has it. UML is still as standard and as next to useless, as it ever was and Rational Rose is still over priced and still flakier than VB6 on a good day. Modelling is still hard and few have the resources to do it at all let alone properly. I'd call it an opportunity for a major rethink and a developer driven push to update or replace UML with something practical and the tools to match. Time to stop being pushed into an inadequate way of thinking about software design by the limited range of agreement between a bunch of bickering professors.
I'd like the kind of tools building architects have where they can wander around a building before they've built it and check out the view from the 5th floor balcony. Where they can try out different lighting designs and see what effect they'll have, calculate how much material they'll need automagically and see whether standard stairwells will fit or not. We wrote those tools so why can't we do as well for ourselves?;)
Feel free to Soapbox this thread as you see fit.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Matthew, are there at least some commonly accepted Best Practices for documenting projects ? I have already decided that we will use Doxygen to document/comment the source code, but what do we use to depict the actual design/architecture/data flow/etc of our project ?
Regards
|
|
|
|
|
Hi
I have again some problem regarding windows registery.
I am trying to delete a key and it's sub keys and all
the corressponding values.
Here is the code which I am using:
HKEY m_htKey;
LONG res;
const char* lpSubNsKey = "SOFTWARE\\N K Product";
res = RegOpenKeyEx(HKEY_CURRENT_USER ,lpSubNsKey,0,KEY_ALL_ACCESS,&m_htKey);
if (res == ERROR_SUCCESS)
{
//res = RegDeleteKey(m_htKey,lpSubNsKey);
LONG status = SHDeleteKey( m_htKey,lpSubNsKey);
RegCloseKey(m_htKey);
}
In the above code,the RegOpenKeyEx() is returning 0 means registery is getting
opened but the SHDeleteKey() is returning 2 i.e. it's error code message is "The system cannot find the file specified".
But the key name is available there in the registery.
So,can you please suggest me what could be the problem?
With Regards
Neeraj Sinha
|
|
|
|
|
You're passing the handle you got back from RegOpenKeyEx, which in effect means you're asking SHDeleteKey to delete HKEY_CURRENT_USER\SOFTWARE\N K Product\SOFTWARE\N K Product, which presumably doesn't exist.
Simply pass HKEY_CURRENT_USER as the first parameter to SHDeleteKey, and don't bother calling RegOpenKeyEx.
|
|
|
|
|
Hi Mike
Thanks a lot for your help.I got it and my problem got solved.
With Regards
Neeraj Sinha
|
|
|
|
|
Hi all
I need a perfect tool to convert microsoft coff format library to
omf format library . Borland c++ Builder coff2omf doesnot work .
please . i need urgent help
RajeshGupta
|
|
|
|
|
rajeshgupta1253 wrote: i need urgent help
that's not a correct way to ask for something, don't you find ? 
|
|
|
|
|
I search a lot like digital mars Borland . but no one works fine
can you suggest me more if u know something about it.
RajeshGupta
|
|
|
|
|
The quest for the PERFECT tool....good luck with that 
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
If I write perfect instead PERFECT whats the result?
|
|
|
|
|
It's less dramatic, for sure
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Hi
I have a realy stange problem with a mfc networking application I am writing (I couldn't see a netwoking message board, and I think it's more of an mfc problem)
Basically I have your standard central server and multiple clients. Clients can connect and run happily doing what they do for hours on end (tests have run for 15 hours no worries) but quite frequently the appliction will freeze at any random time(when this happens all connected instances server and clients also freeze) the cpu usage drops to zero and they do nothing. When I break the app in debug mode (server or client) the code is always waiting at the waitmessage point in the pumpmessage function
//sockcore.cpp, PumpMessage function
else
{
// no work to do -- allow CPU to sleep
WaitMessage(); //STOPS HERE
bPeek = TRUE;
}
The pumpMessage function is called when a non blocking socket is going to block.
I've read a few articles about the pumpmessage function causing a freeze but they all say its for older versions (im using vs 2005).
http://support.microsoft.com/kb/154649
Has anybody else had this problem or does anyone know a solution?
Your help would be greatly appreciated, as I am currently pulling my hair out over this and getting no where.
Tom Hogarth
|
|
|
|
|
|
I suggest reading CSocket Considered Harmful[^].
I generally work with Windows CE devices, so I typically run all my socket code as blocking code on a separate thread and use PostMessage to post custom notifications back to a window for progress updates.
|
|
|
|
|
I've written quite a few networking applications using MFC and found two unbreakable rules:- Never use
CSocket! Use CAsyncSocket. - If the application is multithreaded, all threads that create sockets must be UI-threads since it has to pump messages.
While Matthew and Mike recommends a complete rewrite, I think it would be sufficient to go by the guidelines above and it will probably save a lot of time.
The article Mike linked to is very good and points out important flaws in the design of the socket wrapper classes of MFC. In my experience though, if you adhere to the above, your biggest problem would be a slow DNS lookup.
The part in the article about deriving from both CWnd and CAsyncSocket does not, in my opinion, make any sense. What kind of object is both a window and a socket?
However, you may have a window that contains a socket, or in my case at least a UI-thread.
Another interesting article about MFC socket implementation can be found here[^].
It points out serious flaws in the way MSDN advices developers to write networking applications.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: While Matthew and Mike recommends a complete rewrite
Roger Stoltz wrote: it will probably save a lot of time.
Now or later? See "Technical Debt[^]"
The Microsoft documentation recommends using the Winsock2 library for Socket development. I would heed that advice. It doesn't take much work to write a class that encapsulates the socket handle and the Winsock2 API. Then for async operations you can use Overlapped IO which is also the recommended method for handling async operations. I mean I know it's only 2007 and this article[^] is brand new, only written in 2000 
|
|
|
|
|
led mike wrote: Now or later? See "Technical Debt[^]"
You're pulling my leg, right?
led mike wrote: The Microsoft documentation recommends using the Winsock2 library for Socket development.
 
I haven't found any statement in MSDN that says something like "don't use CSocket or CAsyncSocket".
There are multiple ways of how to write networking applications; using raw sockets or MFC wrapper classes are two of them. Microsoft may provide documentation and examples of how to do it in either way, but I haven't found either of them endorsed by Microsoft.
It could be as simple as I haven't looked in the right document yet... 
My point was that the way Microsoft recommends their own MFC wrapper classes to be used in KB192570 with surroundings does not do the trick, which should be fairly obvious if one reads the article I linked to.
led mike wrote: It doesn't take much work to write a class that encapsulates the socket handle and the Winsock2 API.
Sorry, but my experience tells me that whenever someone put it like that, they are almost always wrong. If they are right it has to be a developer who left the beginner state a long time ago. That doesn't mean you couldn't do it in a heartbeat. ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
The article you linked to looks great at the first glimpse. I will read it carefully when I have the time and try the concept out.
Thanks a lot.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: You're pulling my leg, right?
Ummm No, what do you find humorous about that?
Roger Stoltz wrote: I haven't found any statement in MSDN that says something like "don't use CSocket or CAsyncSocket".
That's not what I said.
led mike wrote: The Microsoft documentation recommends using the Winsock2 library for Socket development.
Roger Stoltz wrote: my experience tells me that whenever someone put it like that, they are almost always wrong.
Then I find your experience lacking
Roger Stoltz wrote: If they are right it has to be a developer who left the beginner state a long time ago. That doesn't mean you couldn't do it in a heartbeat.
First, if you look at my profile you will see I am not a beginner. Second, IMHO, a person should not be writing production socket code if they can't perform the simple task of authoring a Socket class that encapsulates the Winsock2 API and a socket handle.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
). I've always resorted to direct socket API calls 
. At least you wont be hunting for this one for 18 months with any luck