I am debugging a large application, with multiple threads going through the parts I am interested in. I would like to use breakpoints to follow just one of these threads.
In order to do this I am using the breakpoint Filter condition, ThreadId=#. However when stopping and starting the solution, the ThreadId of the thread I would like to follow changes. I currently need to change all of my breakpoint conditions manually by right clicking them in the Breakpoint window, selecting Settings, then changing the ThreadId condition to point to the right thread.
Is there a way to automate this process?
EDIT: For my application, the best way to resolve this was to set Conditional breakpoints monitoring a particular variable which was consistent in the thread I wanted to follow, rather than filtering by thread ID.
If you mean that you want to change the Filter condition breakpoint automatically, it would have a limitation for it.
We could set it using two ways:
(1)Using the breakpoint windows as yours.
(2) Hover over the breakpoint to bring up the breakpoint’s toolbar and click the “Settings…” icon.
Related
I'm trying to lock an entry widget in tool mode like this:
tool
extends Node
export(bool) var locked=false
export(String) var entry="" setget set_entry
func set_entry(new_val):
if!(locked):
entry=new_val
In theory, this should prevent any changes made to the entry widget
as It would rapidly change back to the previous value hence giving the illusion of being disabled
but in reality, you can type freely and after you select another node and then reselect the original node then the value returns to what it was before locking
How do I disable it completely? (perhaps using _set()?)
Edit
This is the problem I'm facing
To disable it completely, I think you need an Inspector Plugin (I talked a little about creating one elsewhere). You could make one that handles the property you are interested in and displays its value, but does not allow to edit it, or only allows to edit it conditionally.
However, for a quick and dirty approach you can do is tell the inspector that the properties changed:
func set_entry(new_val):
if!(locked):
entry=new_val
property_list_changed_notify()
This will cause the inspector to re-read the values of the properties. It can be a bit annoying, depending on the case. By the way, it seems to be ignored in sub-resources, which I find frustrating.
By the way, Godot 4 has PROPERTY_USAGE_READ_ONLY.
Addendum: We can be a little more aggressive than property_list_changed_notify, by using EditorInterface.inspect_object (we can get an instance of EditorInterface from an instance of EditorPlugin). Godot would reload the inspector (which also results in losing the keyboard focus).
Let me say at outset that I'm using old technology by today's standards! This happens in MFC on Visual Studio 2005 and running under WinXP. (If it 'aint broke.... ;-) )
I have a dialog based app which has a CTabCtrl with two tabs. Each contains a CListCtrl. These work perfectly under normal circumstances. They populate correctly and show and hide as they should. When I first open the application the display selection is correct. If I then minimize the dialog and restore, the CList Ctrl does not show, the tab is blank. It is the only control which has this problem. Another CListCtrl outside of the CTabCtrl does show up correctly. If I then swap tabs and back again, the other tab shows up then the first appears as normal.
This does not happen if I access any other part of the dialog before minimising, it is only when minimising is the absolute first action I take. It also happens with the CListCtrl I have in the other tab if I set this tab to be selected on startup in OnInitDialog where I set up the CTabCtrl.
I have actually solved the effect of this problem by adding into my OnSysCommand(...) the following:
if ((nID & 0xFFF0) == SC_RESTORE)
{
m_ctrlReadList.Invalidate();
}
but it bugs me that I'm adding code to solve a problem which only happens in such odd circumstances. I can't help thinking that there is something I have missed in the setup which is leading to this behaviour. Can anyone offer any explanation as to what is causing it in the first place?
My explanation is based on the facts of what I have found but this has been a learning experience for me so apologies if I get some of it a little confused, I'm still letting it settle in my mind.
Along with this problem I found another which turned out to be relevant. From the nature of the program I'm writing, my CListCtrls needed fixed width headers. Now that turned out to be another thing I couldn't set up! I just needed to prevent the user from grabbing and resizing the header's dividers or double clicking them to autosize, and of course there is functionality in the CListCtrl based on its child CHeaderCtrl to set this up isn't there? Well apparently not. LVS_EX_HEADERDRAGDROP for example isn't the way.
So I explored trying to capture messages which would allow me to myself, and what do you know, I couldn't! I could trap a few but not the ones I needed. I was looking for HDN_BEGINTRACK and HDN_DIVIDERDBLCLICK. (We won't go into the fact that you HAVE TO deal with both A and W versions of those separately!) The CHeaderCtrl is a child of the CListCtrl but it sends its messages back to the CDialog as the CListCtrl's parent. I tried there using both my list's and 0 as ID which headers apparently use. Many of them just plain didn't appear there at all.
So I created my own CListCtrl class inheriting from CListCtrl, overrode OnNotify and they turned up there. I simply prevented CListCtrl::On Notify from being called for those messages and it worked, no resize functionality at all.
I also played with the Z-order too which could have been relevant. I didn't explain earlier but this and another list are on two tabs, exactly aligned over each other. Selecting the tabs HIDEs and SHOWs each of the lists in turn. The other list had no display problems even when I changed the default display in OnInitDialog to show it at start up.
It was under the problematic one. So changing the Z-order in OnInitDialog where I set them up - did nothing! And to rub it in that second list was also unresizeable by default just as I wanted and I couldn't find out why. Their Properties listed exactly the same and there was nowhere in the code where any different aspect was set manually for either, they were effectively theoretically identical, but practically not so. So frustrating!!!
And the upshot of it is that now that the header resize issue is solved my display problem has vanished too! It looks to me and to a few others out there too who report similar symptoms as myself as though the CListCtrl is another one of the slightly flaky ones and needs a little massaging to get the best out of it.
I hope that makes sense to those of you out there who know this control well. I was surprised how simple the solution was, but it also surprised me that the diagnostic process was so difficult. It may of course come down to the ageing system I work within. Nowadays I do this only for fun and the expense of updating VS from 2005 for occasional use is not a high priority. I am sure that some of the symptoms will not show under other build and run environments but it may be worth having the issue and my solution on record somewhere for Google to find for others.
I have a window, with several Gtk-2.0 widgets. One of them is a GtkEntry, with the corresponding GtkCompletion connected.
I need to debug the code called when a selection ('match' event) is made in the dropdown shown by the GtkCompletion. So I set a breakpoint, activate the selection, and the entire desktop hangs. The only form I found to get out is Ctl-Alt-Backspace, and delete the gdb instance.
When this happens, the entire windows manager remains as if the dropdown is still active - only responds to Ctl-Alt functions, like Ctl-Alt-F2.
I tried the --sync commandline option, but that didn't make any difference. Though there seem to be some (rather complicated) solutions such as running a nested Window server, or debug remotely, I can't imagine there isn't a more elegant solution.
Any suggestions?
I do this all the time.
You need to grab another laptop, or a console on another server, and ssh into your primary desktop/laptop. Start your GTK application on your main desktop/laptop, then attach gdb to it from your connection from your other laptop/machine.
Then, you will run your gtk application on your main screen, and debug it from a separate connection, without interfering with your primary display.
EDIT: I see that you already considered remote debugging, but in my experience it's really not that difficult. I just have another laptop on my desk, next to me, to debug my X applications.
I am debugging console application, it has several threads running. Then why Thread Window is empty in VS 2010? I do not see any thread listed here, even main thread is not here. Do I need to enable something?
Seen in HansPassant's comment above: This is normal, please try to set a breakpoint or utilize Debug + Break All.
Do anyone know why FocusOut event is not working on linux?
I have 1 enabled textbox and 3 disabled combobox.
I bind the textbox with FocusOut event where it will call a proc that enables or disables the 3 combobox.
It works perfectly on Windows. However, it doesn't seem to trigger the FocusOut event when this action is done on Linux. One weird thing is that if I click on buttons, FocusOut event seems to be triggered.
Could it be because my combobox are disabled?
But why does it work on Windows?
I really hope someone can help me please.
Thanks in advance.
I have observed in the past that some window managers steal the focus temporarily from Tk on each button click before setting it back; I suspect that this has to do with the way that key event handling works, but I am unable to check at the moment (due to being on OSX, where things are different). Because of the complexities involved, I'd suggest that if you bind to <FocusOut>, you should also check whether you get a <FocusIn> event shortly after; a little extra delay (e.g., 0.1s) before doing the update of the buttons' disabled status will not hurt.
Or you could hang the code to do the disabling off the entry widget validation engine, perhaps like this:
.e configure -validation focusout -validatecommand doButtonEnableDisable
The validation interface is the same for both the old style entry and the new style ttk::entry widgets. It's also supported by spinboxes. Just be aware that you need to return a boolean true from doButtonEnableDisable or you'll reject the change to the entry, and you should take care to ensure that your code does not produce an error or it will disable itself; the docs list the things to watch out for.