From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error -200279 being generated because of modal dialog box

In my LabVIEW application, the user can click a button and pop up a dialog box to enter comments about an experiment that is ongoing.  The comments get timestamped and added to a text file for the experiment and added to a blog-like notepad on the screen.  The only way I've been able to get this to work is by making the dialog box for entering new comments modal.
 
This works fine if the data acquisition isn't running at the same time.  The problem is that when the DAQ is going on, I overflow the buffer and get error -200279.  I have two potential approaches to solving this problem and haven't gotten either one to work yet.
 
1) Make the dialog box non-modal.  Every time I try this, I can't enter data into it at all--it pops up behind other screens if I select default mode and I can't focus on it in either default mode or floating mode.
 
2) It isn't critical if I lose data in this application, so I'm willing to ignore this error if I can't find out a solution via approach #1.  Is there a way to configure DAQmx to ignore this error?
 
--crs98
--
A picture is worth a thousand words, but it takes three thousand times the memory...
0 Kudos
Message 1 of 7
(2,605 Views)
You should fix the window problem rather than trying to ignore errors. The latter is almost never the right approach. There are a few possible things that are going one. Could it be that your main window is set up as a dialog? Do you get a computer beep when you try clicking on the popup? It could also be that the main window is coded to always bring itself to the front. Did you write the application? Have you tried to programmatically bring the popup window to the front when it starts up?
0 Kudos
Message 2 of 7
(2,587 Views)
I did have the main program set up as a dialog box.  I've changed that to being a top-level application window. That did solve the problem of having the main window always keeping the focus.  It doesn't solve the problem of running out of data because of error -200279 though.  Is there a way to keep the execution of the main application window going and not being blocked by waiting for the popup dialog to complete?
--
A picture is worth a thousand words, but it takes three thousand times the memory...
0 Kudos
Message 3 of 7
(2,578 Views)
Yes, you have to launch your popup dynamically using the VI Server. Thus the main VI will not wait for the subVI to finish and will continue on its merry way. It's quite easy:


Message Edited by smercurio_fc on 05-30-2007 11:11 AM

Message 4 of 7
(2,574 Views)
I have the dialog box popping up using VI server, and I've figured out how to load in the font panel objects using the Ctrl Val.Set [Flat] invoke node.  Do you have advice about the best way to retrieve the input from the dialog box?  I've tried using the Ctrl Val.Get [Flat] invoke node, which works OK, but it will return immediately--before the user has typed anything into the box.  My current thought is that I could poll the dialog box control using the Ctrl Val.Get [Flat] invoke node in a while loop (at least until the reference is no longer valid because the user clicks OK/Cancel and the dialog box closes), but this seems like a waste of resources.  Is there a better way to retrieve information from a dialog box that you've started using VI server?
--
A picture is worth a thousand words, but it takes three thousand times the memory...
0 Kudos
Message 5 of 7
(2,557 Views)
There's a variety of ways to do it, but as far as the "best" it depends on the architecture of your main program, which I don't know.
  • If your main VI is set up as an event-drive framework (using the event structure) you could trigger an event from the popup dialog via a control's value change event. You just need to pass the control reference to the sub VI.
  • Instead of polling for the reference you could use a global variable. Same mechanism that you're using now, except you wouldn't have to check for errors against a null reference.
  • You mentioned that the popup is intended to provide the user with the ability to enter a comment that gets added to a text file. Could the popup do this directly, rather than passing the information back to the main VI? (Again, I don't know the architecture of your main VI.)
  • You could use notifiers. I've attached a simple example (LabVIEW 8.20) to show you this method. The popup was created using the "Prompt User" Express VI as a starting point.
If any others are watching this thread, please post any additional suggestions you may have.
Message 6 of 7
(2,548 Views)

Thanks for your suggestions.  I'm not using an event-drive framework, so option #1 won't work.  I thought about using global variables, although I'd still need to know when the changed value was valid, which means polling a second global variable for status, which seems like a wash compared to just looking at the controls directly.  Your third suggestion about just using the dialog to write to the file directly won't work for me either as I need the text that the user has entered elsewhere in the main program (the text file that this gets added to is just a log of what gets done during the experiment).

Notifiers look like a perfect solution though.  Reading about them in the online help, that seems just exactly what it is I'm looking for -- a notification that the value I'm looking to read is valid without having to poll for it.  Thanks once again!

 

--
A picture is worth a thousand words, but it takes three thousand times the memory...
0 Kudos
Message 7 of 7
(2,543 Views)