As in any debugger I set a breakpoint at the line I want to debug, then I start debugging but there is no panel on the right side of the screen which displays the current values of my variables. How can I turn it on?
Start a debugging session and visit menu Window > Views > ...
There you can check/uncheck many choices including Reset to Default Layout
Related
I am developing a UWP application for Windows 10 using Qt for UWP.
One of the UI elements in my application is a QComboBox. The application's logic and the corresponding UI works as expected when the default value (text) is not changed.
However, when I select a different value from the drop-down list, the selected value is not displayed once the drop-down list closes. The box still shows the default value (text). But when I observe the value received by currentIndex, it corresponds to the selected value. Whenever I select a non-default value, the UI seems to be blocked. I cannot interact with any other UI elements except the QComboBox element.
Has anyone faced this problem before? How do I ensure that the current selected values is displayed in the QComboBox?
UPDATE:
I built a demo application to check the QComboBox functionality on its own and I see the same behavior. I just added a few items to the QComboBox widget and built the application with both msvc2017_64 and winrt_x64_msvc2017 of Qt 5.14.1.
When I launch the app that was build using msvc2017_64, I get a window with the QComboBox widget. When I select a value, that value is displayed when the drop-down menu closes.
However, when this is not the case with the UWP application that I build with winrt_x64_msvc2017. It does not show me the updated value. It stays stuck at the default value.
Another problem that I observed in my original UWP app was that whenever I click on the QComboBox and select a value, I do not get control of the UI back. Everything in the UI is stuck but whichever button I click is emitting the signal in the background. The UI does not respond at all.
UPDATE 2
I was tinkering around trying to understand what was causing this behavior. During this process, I stumbled upon a workaround to get the UI to respond again. If I launch a QMessageBox within the QComboBox's currentTextChanged signal, I get the UI control back (the currentText changes to the value that I previously selected) when I press OK on the QMessageBox pop-up.
I do not understand why this workaround gives me back control of the UI and gets things working. Please help me understand this.
Windows 10 SciTE 3.6.6
I have a window with a toolbar that contains a drop down that I am trying to get a value from but I am unable to find the window handle
The menu and item looks like this
I need to wait for a process to finish (but nothing is busy so waiting for a window does not seem to help). I know for sure that the process is finished if this drop down contains a 1, it will be blank while the process is running. I could also check if a sub menu item under Documents is enabled, but I have not been able to find a handle to the menu either.
When I drag the selector from AU3Info over the item outlines the main window and all values in the Control tab are blank
While debugging in Qt Creator (ver 3.4.2), if I hit the escape key (which I tend to do often to declutter my work space), then all of the debugger views including the debugger toolbar become hidden (as expected), but later I can't get them back. If I go under Qt Creator's main menu->Window, then Views is disabled.
Here's an example of a basic window before I click the escape key. Notice I have all of the debugging views showing (i.e. Breakpoints, Stack, Locals and Expressions, etc...)
Here's an example of my window after I've clicked the escape key. Notice how all of the debugging windows are hidden (as expected). My question is, now how do I get the windows back? You can see how the "Views" submenu under the "Window" menu is disabled.
Is there some sort of "Show Debugger Toolbar" keyboard shortcut? Or is there another menu somewhere to get this back? Any help would be much appreciated.
Under the Window menu, enable Show Mode Selector. This will show a strip down the left of your window where you should see a Debug tab you can click on to put Qt Creator back in Debug mode.
In Xcode 4.3.1, I am having extreme difficulty whenever I try to change a build setting such as "Other Linker Flags".
If I double-click, a pop-up shows which ostensibly allows you to add/remove values. However, there is no "done" button and all key combinations I've tried (enter/command-enter/etc...) fail to commit the values I've entered.
It is possible to enter a value without the pop-up by /slow/-double-clicking (WTF, Apple?!?) the edit line. This works, but why the heck does is the pop-up the default double-click result when it seems to be totally useless, misleading and annoying?!?!
A similar question is Editing Build Settings in xcode 4 but bugloaf's question of what to do when there is no "done button" remained unanswered.
This is more to do with how to interact with popovers in OS X in general. "Transient" popovers force you to click outside them to dismiss. Whatever changes you make inside them should always be "committed" by the time the popover is dismissed. This is standard Mac behavior.
So to answer the unanswered question: Click outside the popover to dismiss/commit.
As you ssuggested, you can slow-double-click (once to select, pause, once to begin editing cell) to edit text cells inline without the popover. This is also standard Mac behavior.
The double-click action is a secondary effect and can be taken to mean "give me a bigger editor for this field" - this seems to be just Xcode behavior. File bug reports if you think there should be a better mechanism. Be prepared to describe a better mechanism.
I don't really know how to formulate my question this time...
I have my application with a QDialog as a main window.
The application is getting different values like temperature, humidity and so on from a remote machine.
For development I added a group box with different widgets to simulate these values. I have different limits for throwing warnings and alarms to the user.
For example if temperature rises over 30°C then I open a QMessageBox with the request time (the application does polling at the remote machine) and the current temperature. So this is updated each request cycle.
I use the show() method to bring up the message box which keeps my application running in background. The problem now is: the focus is at the message box and nothing in my main window/ QDialog can be clicked until the message box is not accepted/ has finished.
And that's my problem: in simulation mode I want to play around with different temperature values which I can adjust by slider in the main window. How can I access these widgets/ make the message box somehow "not-blocking"?
Best regards,
Matthias
What you're experiencing is called "modality" of a window. By default, a QMessageBox is "application modal". This means that input to all other application windows is blocked.
To change the modality, use setWindowModality() with a value from Qt::WindowModality just before you call show(). In your case:
box->setWindowModality(Qt::NonModal);
box->show();
Indeed you have a modal message box which is the way QMessageBox is intended to work - ie the user is to be alerted and the ui is protected from further interaction until the user has registered the message, closed the message box and (if necessary) taken any action required in response to the message.
Now if you set the message box modality to Qt::NonModal, (remember to assign it to a variable that won't go out of scope when your application continues after popping up the messagebox) you'll be able to interact with the ui even while the message box is displayed., which I have to say is 'unusual'. If I understand your requirement you will already have the message box up - then while this is still up, you'll then want to play around with different temp values in the main window - to what effect? Until another message dialog box is produced? The message box is going to have to be discarded at some point.
Not only that, but if you show a non modal message box and then interact with the main window, you're quite likely to just have the message box disappear behind the main window, out of sight anyway.
I'd suggest that message boxes are generally treated as intended - transient, temporary modal alert boxes only and that perhaps you require a clearly visible live report/status area in your main window rather than utilizing a non-modal QMessageBox.
Hope this helps
Regards
Roger