Check out following scenario:
A User control which contain two combo boxes...
First combo box contain list of States and Second combo box contain list of Cities. When you select a state the second combo box will contain list of cities using a LINQ query. When you select another state in first combo box the second combo box's items clear and refill. but when you want to open it DING DING! application gets HANG and your CPU will be 100% full!!!
unfortunately no Exception occurs during this operations and i don't know what to do!
NOTE: I am sure my LINQ operations and other operations work good and there is no infinite loop or dirty code or something else!
Any idea or such problem?
Break into the debugger and look at the call stacks of your threads. Are they executing in a loop or waiting on some synchronization? If you resume execution and break again a short time later, are they still executing in the same loop? If your application is pegging the CPU, then there is code somewhere in there that's doing a lot of work. You just need to figure out where that is.
Related
I create an event structure for two buttons, start ROI and stop ROI. When the user presses start ROI it goes to this event and do the following:
check if the camera is open and is in idle
enqueue "none" to the queue to initialize the queue
in the loop dequeue every iteration to find if there's invoked message, which is inserted from the callback
if the element is "invoked" then update the region
The problem I am seeing is that when it is in the loop I cannot press the stop ROI or any other buttons. But the ROI keeps updating. I am puzzled why this is happening.
Could you please help me ?
Thanks,
Edit events for that case (the one pictured in your screenshot) and make sure the box titled "Lock front panel" is unchecked. This should solve your issue.
As far as I can tell from the code you have shown, your event structure should not be attempting to handle the stop ROI Value Change event. It doesn't need to, because the only place you need to respond to that event is inside your innermost loop and there you are handling the button click by polling the value of its terminal anyway.
However as #Dave_St explains, this will only work if the loop runs regularly, i.e. if the Dequeue Element function either receives data regularly or has a short timeout, because otherwise it will wait for data indefinitely and the loop iteration will not complete until the dequeue has executed. Having an event handler for the button click can't help here because it can't interrupt the program flow - the event structure only waits for an event to happen and then allows the code in the corresponding frame to execute.
More generally though, and looking at your front panel which suggests you are going to want to deal with further controls and events, the problem is that you are trying to do a time-consuming task inside an event structure. That's not how event structures are designed to be used. You should use a design pattern for your app that separates the UI (responding to user input) from the process (acquiring images from a camera) - perhaps a queued message handler would be suitable. This may seem harder to understand at first but it will make your program much easier to develop, extend, and maintain.
You can find more information, examples and templates in your LabVIEW installation and its online help. I do recommend using one of the templates as your starting point if possible because they already implement a lot of common functionality and can save you a lot of redundant effort.
I have a treeview and a textbox. As I type in the text box it updates the tree view in real time (filtering by what I type and matching against the objects in the tree view).
The problem is it starts freezing a bit as I'm typing in the box. ie. while the treeview is updating the text box freezes. I have put the logic that populates the treeview in another thread hoping this would make it run a bit faster - which it did, but not enough. I believe it is the actual UI updating which is causing the responsiveness to diminish.
What are some ways that I can tackle this problem? Is it possible to have different UI elements (in this case, the treeview and the textbox) handled in different threads - rather than just the logic which is the case now?
Thanks
Your problem is that only one UI thread exists!
A possible solution to your problem is to filter the treeview after a few milliseconds after the user has made a text input.
Another possibility is to make the filtering in a separate task and the result of the Treview reassign.
I hope this helps you with your problem.
I have a form with 2 tabs. The first tab is boring, the second tab (unseen as default to the user) contains many comboboxes.
Using the FormLoad() event I populate a combobox on the second tab (with around 11,000 items/strings) on a background thread. The sql command to do this is also asynchronous.
Now, in theory this should mean that when the user finally gets round to clicking the second tab (whether that be in 10 seconds or 10 hours) they should be instantly presented with a nicely populated control - but there is ALWAYS a 4 second delay. I just don't get it! If all the heavy lifting is done via the background thread (the whole reason for using them in the first place!), why the heck is my application still slow and unresponsive when the user clicks that darn second tab??!!?!
*Bearing in mind you have to give the application a chance to fill the combo in the first place, plus I know when it's finished populating as the backgroundWorker1_RunWorkerComplete() method fires and sends a debug message to tell me all work has finished.*
Any help will be much appreciated....
11,000 is a lot! The work has been done to populate the comboBox items on the background thread, but the form still has to show all those items. This means the UI thread has to render a proportion of them (or all of them) to the UI (into memory) ready for scrolling; this is what is taking time.
I would suggest overriding the ComboBox control and handling the scroll event yourself. This way you can load a subset of the entire list sequentially when you need them (if that is possible in your case). This will prevent the four second delay you speak of.
I've hit against what I think is a race condition. What options do I have to debug it?
More details:
I have a Silverlight application which uses Telerik grid. The columns can be customised by the user by using a column chooser attached to the grid. In a particular case where the list of possible columns are created via the code, when I open the column chooser and close it, the data in the grid (all the rows) disappear!
Symptoms that I see which lead me to believe it is a race condition:
- If I put a break point at the columnchooser.close line, and when the break point is hit, just continue, the bug is not visible (all the gird rows remain visible)
- If I put a Thread.Sleep(1000) in the code just before columnchooser.close, again the bug disappears
- If I keep the "Threads" window in Visual Studio open while debugging, I see a thread momentarily appear and disappear in the Threads window just as I hit the breakpoint at columnchooser.close
So, I tried the following to figure out which threads are running at that point in time - but no joy:
System.Diagnostics.Process is not available in Silverlight, so I can't do System.Diagnostics.Process.Threads to get a list of the threads running programmatically.
I tried a break point with a "When hit" run Macros.Samples.VSDebugger.DumpStacks, but I couldn't figure out where it was dumping all the stack traces to.
Any help or ideas on what I can do to debug this issue?
Without the code this is necessarily vague, but have you looked into putting a lock on the columns or even the grid itself.
I'm not sure how this would actually work, but if (as you imply) the problem is due to the column chooser and the column creation code trying to access the grid at the same time then this might solve it.
I have this situation where I have a ListBox which is being populated from a background thread (it's an address book and the data is coming from AD).
The problem is that since the list is sorted (using CollectionViewSource) and also available to the user while more data is being retrieved, it's bouncing all over the place as new items are being inserted at various places in the list. So it's available to the user, but mostly unusable since the user's selections keep going out of view.
Is there a way to keep Focus to the item selected, and preserve the selection, even if items are being inserted above and below the selection from the background thread? I would prefer not to sort on the server, which I understand can be a bad thing when it comes to AD.
I'm going to respond to this from a UI design perspective rather then a technical code perspective. (I'm sure someone else will have a way to have the list box keep the selected item in view)
I would argue that the use of a list box while large ammounts of data is being added to it is fairly impossible to do nicely. Lets just say you do get it to keep the selection in view, what about while the user is still searching for their required item, you wouldn't be able to keep it still then.
Firstly if the expected total load time is under 10 seconds you could just disable the list box until loading is finished. (Obviously grey it out with a spinning animation or something so the user can see it's doing something.) I'm assuming you have already dismissed this option otherwise you probably wouldn't be asking here. But I do think this is worth considering. If the load time is farily small consider if your users will really gain anything by being able to browse the list while it is still being loaded.
Secondly, I would propose that you find a way to restrict the contents of the list box so that only small quantities are every displayed at one time. You could do this by only displaying names starting with a single letter of the alphabet (along with a letter selection control). Or you could provide a filter entry text box at the top where the user could type the first few letters and the list box would only display the names starting with those letters. This would allow the user to type say "sa" and the list box would display "sam", "samantha", "sacha", etc. Now you only have a small number of items in the list so you don't have to worry about it jumping around. If the number of items in the list grows too large (because of the loading on the background thread) and the list goes beyond the height of the box the user can simply type an extra letter to futher filter the list.
Sorry if this isn't really what you wanted, but I thought it would be worth bringing alternative design up incase you'd overlooked it.