I am working on some inherited code and I ran across something I've not seen in LabVIEW before...see attached screenshot. Notice when I right-click on the property node and try to find the Terminal...Terminal is grayed out. When I find the Control, it takes me to a blank spot on the front panel that has absolutely no controls (I've ensured that the Control has Visible=True by programmatically setting and verifying that property). I've never seen a Control without a Terminal...what's up? Using LabVIEW 2012.
After quite a bit of digging, I found the answer:
It turns out that the Property Node is pointing (linked) to a control which is buried inside a cluster.
The lesson here is: if Find >> Terminal is grayed out, it's possible (likely) that the control to which the Property Node is linked is inside a cluster. I re-created the scenario with this mini-example:
Finally, I couldn't find the front panel control at the onset because it had its Visible attribute set to false inside the cluster (the cluster was visible, but not the element within the cluster) and it was physically placed far away from the other controls within the cluster, AND it was placed on a hidden Tab page.
Related
I'm working on a project that has needed a TreeView control with multiple columns. After research looked like a custom control was necessary, and to my luck I found a good one on CodeProject: https://www.codeproject.com/Articles/26849/The-TreeListView-To-End-All-TreeListViews
I've been leaning on this control heavily but have run into a few bugs that have been very challenging to work around given that I can't actually access the source code in the project files the developer was kind enough to share. The main issue I'm dealing with is a crash that pops up when the control is resized almost to the point to where a horizontal scrollbar would need to appear. I noticed that when resizing there is a deadzone of about 10 pixels where this control would show the horizontal scrollbar slightly before you'd need to, likely because of weirdness in measuring the indenting widths of child tree nodes. In this state the scrollbar appears, the scroll box fills the entire bar and won't allow you to scroll left or right.
This doesn't bother me other than the fact that if you use your mouse scroll wheel in this state it throws an ArgumentOutOfRange exception and pulls my application down:
Value of '-1' is not valid for 'Value'. 'Value' should be between
'minimum' and 'maximum'.
I'd love to be able to handle this exception but I'm quite new to VB.NET and Windows Forms and am still learning how events are handled. If there is a straightforward way to override the OnMouseWheel event or otherwise handle errors that may be triggered from it that would be fantastic. That or any other suggestions the community may have would be greatly appreciated.
If helpful, here is the top part of the error's StackTrace:
System.Windows.Forms.ScrollBar.set_Value(Int32 value)
WinControls.ListView.ContainerListView.OnMouseWheel(MouseEventArgs e)
The ListTreeView control (one I'm using) inherits from ContainerListView. ContainerListView's OnMouseWheel event is protected. Does this mean that I won't be able to override it?
Thanks, and happy to provide any other information that is needed.
I have a WPF app that I try to automate using testack white and I'm pretty much stuck at the point where I cannot get any children for a Window (which is embedded in a Panel which is the main Window)
The problem I believe is not necessarily with white but how this app is built because (I'm using VisualUIAVerifyNative as inspector. I tried others as well but haven't seen any children in ControlView, ContentView or RawView):
- opening the inspector and expand the tree till that window it shows that this doesn't have any children
window_element_no_children
- however, if I use Focus Tracking/Hover on mouse feature (e.g. while pressing CTRL the inspector then gives you whatever element the mouse is hovering) then the whole subtree for this window then shows up. Unfortunately, even though I try to find the children at this point through my automation test it still returns me none.
window_element_with_children
Does anyone have any idea how exactly I can "force" a check on this window so that the children will then be displayed? Same as how FocusTracking in inspector works like.
Thanks a lot
Have you tried using AutomationElementFinder?
var children = new AutomationElementFinder(window.AutomationElement).Children(
AutomationSearchCondition.All);
You can try other SearchCondition too.
Is there a reason / fix for this weird designer issue (at least, I think it's related to the designer), whereby the controls on the form do not appear as they do in the design window when I debug the application..!
Please see the following two screenshots to demonstrate the problem (note: I have blacked out some of the content of the form, this is not the problem):
Picture 1: Showing how the form appears in the designer view
Picture 2: Showing how the form appears in debug mode
You can clearly see that some of the buttons have moved position on the form.
Note: At first glance, this may appear like a duplicate of: Windows Forms Designer destroys form layout. However, I have not installed any additional tools or components. This is simply a standard "vanilla" build of Visual Studio 2012 on Windows 7 32-bit.
I've also come across this question: UI Controls Overlapping & Fonts Issue in Windows Forms Application. However, I am not using "large fonts", nor am I using any non-standard fonts on my controls (all label and button text is left as default). Still, I can see how this would affect the control positions and will do some more checks in this area.
There's nothing happening within the form's Load method.
I'm also using TFS 2012.
What could be causing this? Is there anything I can do to fix it?
EDIT: I've removed the font property for each label and button control, allowing the system to set the default value. Still no change. Interestingly, if I open the form in design mode, then save it, then close it, then open it again, the buttons have moved... If I do this a few times, the buttons migrate until they're off the form.
OK, I've found the answer, after a bit more fiddling. It seems to be related to the Anchor property on the controls. I made a bunch of changes, testing between each change to see if there was any difference. When I selected all the controls and set the Anchor property to Top, Left, this solved the issue.
I hope this helps someone else at some point!
JavaFX 1.x had a blockinMouse property you could set to stop events propagating down to nodes below (for instance a right click to bring up a context menu when you'd just want it on the top node.)
I'm struggling to find an equivalent in JavaFX 2 though, I'm assuming it must be somewhere but the only things I've dug up online have been similar complaints, and I'd like to avoid the brute force style answer that's listed there.
Seems I was approaching this the wrong way - the solution was to simply call consume(); on the event in the top most node to stop the event propagating down to the lower nodes. The mouseTransparent property was similar but not what I was after, it just controls whether the node receives mouse events or just passes them on (similar to the old glasspane like approaches.)
In JavaFX 2 this is called: pointerTransparent.
Sorry in advance for the vague conditions in which the problem below occurs. It is very intermittent, and I have not pinned down a consistent set of steps that reproduce it yet. (Which is why I'm asking for some general or common things that might cause it)
The application I'm working on consists of MonoDevelop.Components.Docking dock frames. There is a tabbed group of panels in one if the frames, and one of them has a GtkTreeView in it. Every now and then, the nodes of the Treeview will not expand when clicking on the + button. This does not go away until restarting the application.
However, since I have not been able to consistently reproduce it, I'm kind of at a loss of what to look for/mess with to fix it. So does anyone have any ideas on what might generally cause the nodes to not expand when clicked? Or any better steps I should try in order to reproduce it?
I have found this occurs when a disabled node is in the TreeView. In my case it was a project in the solution pad of MonoDevelop that was set to not build in the current configuration. When I removed the project, all other nodes in the TreeView started working again immediately.
You can use the arrow right/left keys to expand/collapse nodes.
It may be related to a Gtk bug:
https://bugzilla.gnome.org/show_bug.cgi?id=675835
which was fixed recently:
http://git.gnome.org/browse/gtk+/commit/gtk?h=gtk-2-24&id=b32a9eb691920f21ad3b9127c833aaba15727c4b