What MFC control should I use and how should I use it to display constantly changing text (like progress text) on a dialog?
For example, should I use the static text control? But can you change it programmatically?
Yes, you can change the contents of a static control programmatically. Change the ID to something other than IDC_STATIC, then you can assign a member variable to it. You can set the text with your_var.SetWindowText().
Edit: how many changes are you making, and how fast? I did a quick test program with a timer (set to a duration of 0) that formats and writes a new string to the control when the time fires, so it's updating constantly. Here's what it looks like after running for a while:
And here's what Task Manager shows:
The spike a the right is (at least mostly) from taking the screen shot of the test program saving it, and so on. As soon as I quit doing things like that, CPU usage went back to do noise level (with the occasional blip). I left the program running -- a half hour or so later, it's still doing fine, with no noticeable CPU usage (in fast according to Task Manager, it hasn't used even one second of CPU time yet).
Related
This seems to be a bit of a tricky one. Problem observed on Qt 5.9, 5.12 and 5.15.
In the app I am debugging on Mac (Jamulus), there is a main app window, and a non-modal tabbed settings window in which there are some QLabel items that get regularly updated with data values (a couple of times a second).
The problem is that if the settings window is displayed, but is not on top (the main app window is on top), and the user is not interacting with the program, the label updates result in steadily increasing memory usage. Then after some time (10 minutes or more), when the user next tries to interact with the program, the program goes busy (spinning ball) for a significant time before resuming. Once the program has resumed, the memory usage has gone down somewhat.
If the settings window is on top, the memory usage does not increase significantly.
It seems like there are objects being queued for deletion by the label updates, but that these deletions are only processed when the owning window is on top, and otherwise are queued for an event loop that doesn't run until the user interacts with the program again.
Is there a way to ensure these queued deletions get processed in the background as soon as they can be, rather than being queued up for a long time?
One further data item is that an older version of the program did not use a tabbed dialog for the settings window, just a simple dialog, and it doesn't suffer from this problem. It seems that maybe the tabbed dialog somehow gives rise to the issue.
This issue has only been observed on Mac, not on Windows or Linux.
I would like to use the debugger but I have two problems
I am using SDL to create a graphics window, when I run my program in Debug mode I can no longer see what is going on in the window.
When you are simulating physics the time elapsed affects the behaviour of the program but when you are debugging the time elapsed and the code are no longer in sync so the program cannot behave normally. What strategies can I use to overcome this?
Redraw the window more frequently in the places that you want to debug, for example do one step code line to draw the line then next step line to redraw the window. Use 2 monitors so that debugger is in one and your program in the other. If you don't have 2 monitors then it will be a little inconvenient to debug but you can make your debugger window small and place it in one side of the screen and have your program running on the other side of the screen.
I must admit I don't know anything about simulating physics. If that's something where you use many threads and the order of execution matters between them then you can place breakpoints in each thread and then switching between threads you can step over and decide which thread and how far should progress. If that something within single thread then you may want to add a code which will be altering the time elapsed. Perhaps you could implement kind of simulator which would make sure the elapsed time in the given place of the code is as you would normally expect.
I have many different VBA macros that are commanded to run by an analysis sequence this analyser sequence and a Labview VI also reads and takes information that has been calculated in the excel spreadsheet.
The analysis sequence has timers and delays that you can see counting down during which it checks on the status certain cells of the excel spreadsheet.
All the analysis sequences, excel VBA macros and Labview VIs work perfectly but only when the excel window is running in front. if any other window is selected the calculations slow down which means the delay timers shown on the other sequences also slow down 5 or 6 times slower.
This becomes a problem because the Labview VI has buttons to select options meaning in normal operation the excel sheet won't be in front.
I have tried changing priorities in the task manager which changes nothing and making things run on different CPUs which again does nothing. the CPU is running around 50% all the time but the CPU usage of excel jumps from 2 or 3 when excel window is up front to around 50 when another window is selected.
I've also made the macros as streamlines as i can think of doing by turning of screen updating and so on.
A fix like the VBA code bringing the sheet to the from will be just as good as having the excel window permanently at the front. but an idea of what could be causing the issue would be much appreciated.
Thank you in advance
You could try setting your Windows environment to adjust for best performance of background services.
http://www.ni.com/white-paper/3773/en/
There are some controls on windows phone that behave different on the first interaction with them than on subsequent ones. e.g. a button control takes about 3-5 seconds to initialize the required action the first time the button is pressed, however on subsequent clicks it works immediately.
Another usercontrol that adjusts its height based on the key press doesn't adjust properly the first time, however the second time it works.
Is there a way to either prepare the controls, i.e. set them in a ready state so that all the clicks behave the same, or can first click can be faked to bypass this annoying behaviour?
Also what is causing this problem?
NB:- I am testing on a Lumia 520 device.
Unfortunately There is no way to prepare the controls. Nokia Lumia 520 comes in Lower Memory Device So Its behaviour seems slow at loading first time in memory and there are so many Background tasks also runnig at a same point of time. You should try it in Higher Memory Device and see the Behaviour.
I found out from this app performance document why it was happening , http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff967560(v=vs.105).aspx#BKMK_Applicationstartup.
I have a loading panel that is set to collapsed by default and only set visible once the button is clicked. According to the document, elements in collapsed state arent added to memory, so this means the first time it needs to initialize the panel and it doesnt need to in subsequent tries.
The other UI control behaving weirdly was also due to its parent's height not being adjusted after its own height is adjusted the first time, so adjusting the parent height as well fixed it.
I develop audio plugins, which are run inside their hosts and work realtime. Each plugin has its own window with controls, which often contains some kind of analysis pane, a pretty big rectangle that gets repeatedly painted (e.g. 20-50x per second). This is all working well.
The trouble comes when the user adjusts a parameter - the plugin uses WM_MOUSEMOVE to track mouse movements and on each change calls ::InvalidateRect to make the relevant portion of the window be redrawn. If you move quickly enough, the window really gets quickly repainted, however there seems no time for the host and other windows to be redrawn and these usually perform some kind of analysis feedback too, so it is really not ideal.
No my questions:
1) Assuming the host and other window are using ::InvalidateRect too, why mine is prioritized?
2) How to make ::InvalidateRect not prioritized, meaning the window needs to be invalidated, but it may be later, the rest of the system must get time for their redrawing too.
Thanks in advance!