Hey Mark, thanks for your reply - i was in fact doing almost same things :P. Well, but, thats it, and thank you so much!! I got rid of AcceptEx call, and, implemented accept event (like you do) and now it works!! Finally!
I got rid of AcceptEx call, and, implemented accept event (like you do) and now it works!
It was so long ago I forget why I don't use AcceptEx()...but I'm sure I couldn't get something to work the way I needed to
I do really like I/O completion ports. Not just for I/O... For native C++ apps they make a nice built-in thread pool for queuing operations on worker threads. Very efficient and Microsoft did most of the work
I am working with IOCP just for a 3 days now (current project requirement) and starting to love it. Completion ports are a way better then creating tons of threads for connections and tons of events as well - you got everything in one place, its like, kind of message loop, isnt it? having one struct, jumping from reading to writing and queuing stuff, defying operations, and performance for sure. Totally agree - IOCP is outstanding option - one port to rule them all Ok, back to coding
There are articles and even classes to tell how to dynamically move controls on forms.
I thought it should be a simple task to dynamically expand (MoveWindow) a control to fill available space under different user options, however, I cannot figure out how to dynamically determine the actual location of the new destination / size.
I have added an anchor button to get the location but I do not know how to dynamically get the location of this button.
I tried GetWindowRect , but that gives me location relative to the current window. GetClientRect gives me the actual size of the anchor button and that is no help either.
The “anchor button” is off the screen when the user selects the option and I use scroll to (up) bring it into view. Is is possible this is my problem and I need to recalculate the position after the scroll?
Still using VC6.0 and MFC, the app works for me, and no, updating to anything is not an option. Do not waste your and my time suggesting it.
Any constructive help will be as always appreciated.
Using GetClientRect() on your main window will tell you how much space is available, so you can resize your control to those dimensions to get it to fill the space. Also, I'm not sure how to do it in MFC, but in Win32 the structure filled by the BeginPaint() call will also give you the dimensions of the visible part of your window; maybe part of the CDC class will help.
I am using visual studio 2008 MFC feature pack. My application has a "quick access toolbar" which is included in the MFC feature pack (it can be found at the top left of the main window. right next to the main menu).
My application is localized to several languages. Unfortunately, I can't find a way to translate the quick access toolbar and it's sub enries ("More Commands...", "Show Below the Ribbon" and "Minimize the Ribbon").
Does anyone know how to translate the quick access toolbar?
My problem is When I click the first Dialog, Focus doesn't switch to the first Dialog.
I've to minimize the new Dialog, if I want to see the first Dialog. How to set Focus
to a Dialog while it is clicked or pressed ALT+TAB?
1/ Unless you *really* know what you're doing it's a bad idea to create UI objects from multiple threads. It's like juggling with loaded guns whilst drunk. Sure, it may seem like a good idea at the time, but someone's gonna lose a toe.
2/ TerminateThread is also a really bad idea. I don't think I have *ever* used it. I've used plenty of Events, and BOOL's, and WaitForSingleMessage (hSomeThread, dwA_short_time)'s, but never TerminateThread.
That way memory leaks and crashes lie.
3/ To answer your actual question...
Ptr->SetFocus () ?
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
1/ Unless you *really* know what you're
doing it's a bad idea to create UI objects from multiple threads. It's like
juggling with loaded guns whilst drunk. Sure, it may seem like a good idea at
the time, but someone's gonna lose a toe.
2/ TerminateThread is
also a really bad idea. I don't think I have *ever* used it. I've used plenty of
Events, and BOOL's, and WaitForSingleMessage (hSomeThread, dwA_short_time)'s,
but never TerminateThread. That way memory leaks and crashes
3/ To answer your actual question... Ptr->SetFocus ()
You showed two pieces of code. Only one has "Ptr" in it. Look up SetFocus on msdn for more information on that member function. The name is a bit of a give away though.
The second piece of code you showed implied you have threads creating dialogs. My points about threads and TerminateThread applied to all windows programs, not just the bits you shows.
Just in case I misunderstood your question, when I used "Event" above, I meant Win32's event synchronisation objects, created by
CreateEvent win32 function.
If you've not heard of them (and mutexes [*], and semaphores) then you really should not be creating windows outside the main thread. I may sound harsh, but I simply mean you should not be using them *yet*. Do some reading, play with some programs, understand the ideas, then go wild.
ON_COMMAND macro create a set of code that ensure the call of the function.
I guess you don't understand what the purpose of the ON_COMMAND macro is. Adding this to your program creates the code that will be called when the TEXT_2 command is invoked by the user. If you do not have any way of invoking the TEXT_2 command then this code will never run.