Having a timer activate every millisecond involves using something like sleep_for, right? Is that less susceptible to delays than wait_until is? Either way, it does certainly having the advantage that any timer-related delays won't block the main thread.
I doubt your condition_variable::wait_until code is causing the redraw delay based on what you've shown.
Invalidating the rect simply creates an update region and then marks an internal 'dirty bit' associated with the window. The operating system is somewhat lazy updating the window... it could be redrawn a few milliseconds later... or several seconds later depending on how many messages are in the message queue.
If you want an immediate redraw add a call to the UpdateWindow function immediately following your invalidation.
While I must admit that I don't know how to gracefully debug the timer, I'm pretty sure the join call is producing at least some of the noticeable delays. I tried just adding an UpdateWindow call after the InvalidateRect call in turnTimer as a simple test, but that deadlocked the program, which led me to read about how it's flatly incorrect to do a lot of kinds of window manipulations from another thread. I'm not sure if InvalidateRect is one of them and I just kept getting lucky with the original implementation, which also called it from the timer thread, but I suppose the fact that I'm not sure is enough reason to switch to something like Daniel described even if I weren't getting the lags. I'll try it and see what happens.
I'm looking for a way for my application to receive a notification whenever the PC connects to a WiFi network. I need to know the name of the network so that I can configure stuff differently depending upon which network the user is connected to.
However, it looks like that function is for receiving notification of connections to network resources on the network that you're already connected to. It is not for receiving a notification of actually connecting to the network itself.
Program is throwing exceptions "This command is not available" while calling "Editpaste" and "Editreplace" functions from code in Word automation. This is happening sporadically not every time. Any suggestions please?
You have either set the C++ standard flags low or the default on your compiler is not c11++ or greater
I have no issue with GCC or VS2017 taking structs like that.
try the flag
or I would probably try and see if it is available
BTW if it is actually a C file you need different flag .. I know you were playing with C files before
Now that I think about that I am guessing that is the issue you are compiling C files with G++ .. don't
Setup your make file to send C files to the c compiler gcc, you can make a rule based on the extension .c vs .cpp
.c files => gcc
.cpp files => g++
Visual Studio actually does exactly that it uses the filename extension to decide on c vs c++ compiling, which is why it works on it.
No, there is no problem listing files found on HDD, but setup them an icon (in CListView of course) just like Windows Explorer does, and then have the same contextual menu like Windows Explorer has ...
I am really sorry because I was not clear on my first post.
Let say I list a text file in my CListView. And I must setup an icon to that item, but that icon should be exactly like in windows explorer. I mean, if a text file in windows explorer has a Notepadd++ icon, I wish the same icon to my CListView. The same matter if I list a pdf file ... if this file has a pdf icon in windows explorer, I wish to have the same icon to the item that list that pdf file in my CListView.
And if I see in windows explorer a contextual menu, I wish to have the same contextual menu in my CListView.
I’m again having different results in debug and release this one isn’t a bug but different program behavior.
I have 4 CwinThread Wrappers for CAsynSocket
In debug because processing is slowed somewhat by int 3 breakpoints I Receive all my about 3500 bytes of data from the Mainframe computer. In release I don’t get it all in one transmission I have a full word or a short int in the begging of the stream to tell me how much data
My method to debug this in the past was issue a AfxMessage and attach the debugger
This always seemed to work with the Mainthread
I didn’t even notice the message box come up in this scenario except by hovering my mouse on the tray at the bottom of the screen I don’t think I can use __debugbreak in Release
Anyway to stop this thread so that I can attach the debugger to see what’s going on
I forgot to add this UI thread was created before I created the CMainFrame Window however in the past I was able to have an AfxMessageBox in the CWinApp constructor and it worked
modified 6-Dec-18 10:10am.
Last Visit: 21-Apr-19 10:03 Last Update: 21-Apr-19 10:03