WM_PAINT is intended to be a relatively low-level thing - drawing, not calculating and not resizing the window and not allowing menu choices to be made... (it only even gets called when there is absolutely nothing else to do). you should definitely be doing nothing but painting there. After...
swapped-in text (code) segments are backed by their original code on disk; perhaps the swapper code simply doesn't support any other arrangement. just a guess.
let's see... load a dll from over the wire and execute its contents. no, i can't see ANY security issues THERE. <g>.
you could also create a dll contaning a self-contained debug window on a separate thread, and send messages to the window to add debug text. Easy to do, except you either must hardcode the createwindow/createdialog call in the secondary thread or (as i do) the class that handles this mess has...
are the dialog controls custom or standard? if they are custom, you should be having them send WM_CTLCOLOR* messages to their parent (ostensibly the dialog box itself) to try to get the correct background brush. (You should also handle WM_ERASEBKGND and zero the background brush field in the...
Your code has 1 big bug - you are opening the file for overlapped I/O, but you're not actually HANDLING overlapped I/O. For example, you are treating ERROR_IO_PENDING as a failure, but it is not. It is a normal result of overlapped I/O when there is insufficient data to satisfy your request or...
a homebrew fragile algorithm that half-works is simple (obviously! haha) but the CORRECT algorithm that works across character sets is in the library functions strtol() and strtoul().
i work around this problem by using a custom control class instead of the built-in static control, which is REALLY REALLY easy to do. Whenever the custom control is resized or when its text is changed, recalculate its own size. the next WM_PAINT will fix it nice & pretty. I also send a custom...
Ideally, all 3 of the basic comm I/O tasks should be performed using overlapped I/O. this can correctly be done with either one thread (doing all comm port I/O, which i have found to work quite nicely) or with up to 3 threads (one for input, one for output, one for status changes, if important)...
never convert numbers using knowledge of the ordinal positions of the numeral inside the character set. it would be like upshifting letters by adding & subtracing the biases into the ASCII uppercase/lowercase sequence. use the library conversion routines instead, as they work for all...
whether or not to support multicharacter substrings is a matter for the function's documentation, altho i agree that failing to do so (given that the substring is not a w_char/char argument) is somewhat impolite.
whatever you do, just get that call to strlen() out of the loop!
if course, if this is a child window you're painting, you'll want to send the parent the appropriate WM_CTLCOLOR message first and see if you get a handle back; if so, that's the dialog's suggested background color.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.