Michael Aivaliotis

I don't think you need to re-write, just yet. I've managed to shoehorn-in gradual enhancements to software in a similer situation.There are many file IO implementations to do what you want but I won't get into that. I've attached some code that implements an architecture for handling configuration data within your program. You have to fill-in the code for reading and writing to the actual config files. For this you can plug-in the openG config VI's if you want but that is not the point. The point in the attached example is that the locals are replaced by a functional global. Wherever you need to read from the config data you place this down and unbundle the required parameter, or all of them. You should only write to these parameters from the configuration window. The nice thing about this is you can place the functional global deep within any subVI's you may use and you can avoid wiring messes. Download File:post-2-1138297260.llb

That is still slow. What SQL statement are you using? Also, have you indexed your table?I just did a simple test with: SELECT * FROM `databasename`.`tablename` of 1000 records and it takes: 15ms.

That's awsome! Also thanks for replying and letting us know the fix.

Whould you be willing to post this DLL here so we could try it out?

If you add a larger delay like 10ms, you will see they are much closer. Are you running this on LV RTOS?

This is not a bug, nor is it a problem for LV8 only. If you select the entire listbox so that a flashing dotted line is around the listbox, then go to the font settings and select the font and size, the setting wil propogate to the entire listbox. I tested this and it works for me.

Here is IOWA state university CSIDC 2005 final report. It includes lots of information on Cubix, very nice. Download File:post-2-1138116006.pdf

I think that Jim's approach would be the best and is not too bad to implement. You already have the mouse coordinates. You could (and should) use an event structure to trap user clicks on the picture control. No matter how you look at it, however, you have a tough challenge. Sometimes the easiest solution is to just remove the requirement. Do you really need this GUI or is there some other approach.

Is it me or is there just way too much interest in doing DAQ with the parallel port lately. What is the reason for this? I just don't get it...

Yes, well this is a known (to me) bottleneck with the LabSQL stuff. There are changes you have to make to some VI's that may speed things up. Here are the two VI's before: And here are the two VI's after:

I would suggest you at least use a state machine. You will quickly find that your program will be more difficult to manage as time goes on. State machine architecture helps as you add more and more functionality over time. This is always the case with LabVIEW code. Here is the FAQ link on them: What is a State Machine?

Maybe you can educate us a little bit. I've worked with several database engines but not SQLite. I understand it's embedded. Does this mean you cannot access it from an ODBC interface? Can you create a DLL that can be called through LabVIEW?

You probably need fast updating because you are using the GUI as feedback for some manual tuning operation that the operator performs?Are you using an event structure? If so, then I don't see how you can miss user events. They are qeued up in the event structure. I'm not sure why you are having such problems with slow screen updates. Is it possible to see an image of your code?

Yes, well what you want is to isolate the main GUI from knowing or even caring about the representation requirements of the test routine. One way to do this is to build a framework into the main GUI that calls various methods of the routines. This is where GOOP helps. For example, you would make each test routine a class that has several methods. One of the methods would be "run test", and another coould be "display data". When you call the "display data" method, you would pass it a reference to a location that you want the data to be displayed. The location would be an embeded panel. Now, the GUI doesn't care how the data will be displayed. All it knows is that data will appear in this embeded panel. You can really do some powerfull stuff with this. For example you could call the "display data" method multiple times. Each call would create a new instance of the data display object. This would allow, for example, multiple views into the same data (one graph zoomed, another expanded). You may ask the question. So how is the data displayed. Well, this is the exclusive responsibility of the class. It has knowledge of the data and would have a VI panel dedicated to this. This could be a seperate VI or handled within the same test routine. Now, you could even go one step further and make the "data display" a class. Then you could make it generic enough to handle your data. Your test routines would call this class and pass them the GUI reference. Let's face it, how may data types do you have? Graph, Boolean, String, Numeric. If it can handle those then you're golden. Also, don't lock yourself into the very limiting "Main Window" concept. With the approach mentioned, you can have multiple windows, each displaying a different piece of data. Your customers will love you for this.

Well, I'm glad to hear that it's a bug rather than some strange attempt from NI to remove functionality. It's a shame since this is a useful function for implementing some powerful design patterns.btw, is it me or is this the buggiest LV release yet?

Ah, so now we get down to fixing your real problem. You have queue backlogs? How can we fix this? Have you tried "deferpanelupdates"?

Just a quick thought. Many of the packages have dependancies. This means packages depend on other packages to be installed. I think the problem is that you need to install the oglib_error-2.2-1 package as well. The current released version of Commander does not have dependancy checking. This is a future feature.

Your code looks just fine, I really have no idea why you are getting this. Before you install 5.0 make sure to download the latest ODBC driver first since this may be the problem. Also make sure that you are not modifying any of the ODBC flags in the driver. Leave everything as default.

I will try to reproduce this however, I am using MYSQL 5.0. Perhaps this makes a difference.

Whe I tried this from the database toolkit, it works fine for me. I used the SQL query: SHOW columns FROM test_table It returns all information. Here is the code I'm using:

Well, you can always write to this programmaticaly using the ini write functions from within your application. You can access the value of this path using the Default Data Directory constant and property:

This is the preferred usage of tabs that I would like to see. I have seen main UI windows implemented with tabs and I got to say it stinks. What it comes down to is the programmer's lack of creativity in presenting data and information to the user. Yes, let's slap a couple of extra tabs to cram some more data into an already crowded front panel. See a great example of how not to use tabs:http://forums.lavausergroup.org/index.php?...pe=post&id=1912 If the purpose of a tab control is to navigate the user through some tasks then use a tree control on the left side with revealing information on the right. Again, the underlying thread should be static properties that can be changed or manipulated. Once this is accomplished, the window is closed and forgotten. Well, cool, this can happen but I am totally against using the tab control as something outside it's intended purpose. I also find it annoying when I have to "decode" the GUI just to find some input and output controls that should be right out in the open. You don't need to hide the controls or indicators. The less editing of the code I do the better. If a panel resizing will reveal a control then they can be placed to the left of the GUI objects. Panels only resize to the right or down. Why are you thinking of this? Why would you want to make such a complicated GUI window? You need to analyze and find out what your lowest data object is and how it can be displayed. Then decide how multiples of these data object can be presented as a group or individually. What are their relationships and how will they be manipulated by the user. There are many directions you can go here. For example, multiple test routines can generate plots that get pushed onto a common graph. This graph would allow you to add or remove plots as needed. You might also allow the ability to spawn multiple instances of these graphing windows all pointing to selective data. Make the user interface generic enough to accept data input from various sources without forcing the user to look at only one thing at a time. This is my main beef with tabs. It allows only a limited view into the system. What is the problem with multiple windows? Why can't I see gauges and graphs and test parameters all at the same time?

Well, maybe as I get older I get less and less adventurous. I am afraid that the only reason I would switch to LV8 is if a customer specifically requests it. Even then I would ask them to give me a compelling reason. It would have to be some feature in LV8 that they can't live without, or something that can't be done in LV7. If you are an integrator and are getting paid time and materials then you get paid either way, but if you are on fixed cost projects then it would be suicide to switch to a new LV version just because NI is preaching about it.

Some support VI's are missing, can you re-upload the zip. Since you're a Premium Member, just go back and re-edit your original post and replace the attachment. No need to re-post.