Jump to content

bbean

Members
  • Posts

    256
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by bbean

  1. I'm familiar with the tree control so I guess what I'm interested in is: 1) What DB tools did you use? labsql, ni db toolkit, or custom, 2) Do your VIs automatically traverse the database to build the tree? 3) If it automatically traverses what technique do you use? thanks.
  2. Slightly OT Forgot to ask about your DB and tree control. Are the VIs you used to populate the tree from the DB proprietary? If not I'd be interested in taking a peek. I guess I'd have to brush up on my ?German? though. B
  3. The tree implementation you show is a pretty neat subpanel implementation. I especially like the icon use in the sublevels. Very professional looking. I have taken a look at the OpenG wizard style used in OpenG Commander. That was my initial inspiration because it looks and feels very professional also. I thought subpanels might help make it easier and more generic. I had another thought last night, maybe it would easier just to make a vi template to use as a starting point for each wizard screen (with queued state machine). Then use this template to create VIs for all the screens and put the screen VIs in a top level VIs to manage the flow. The trick is passing information between each step of the wizard. I'm using some GOOP objects so it may not be as difficult as I anticipate. Anyway this strategy is not as elegant but follows the kiss principle. Thanks for the feedback, Brian
  4. Has anyone tried using a Subpanel and some Back, Next, Finished, Cancel Buttons in a VI as a generic framework for a Wizard style interface? The main reason I'm thinking about doing this is the functionality of many of the wizard screens is also used in other areas of my app where I don't need to lead the user through steps. I've created wizards before using tabs, but thought a subpanel might be better because I could run a subvi in the background for each wizard screen and also call a screens subvi somewhere else if I just want to execute one of the screens. Has anyone gone down this path before. Let me know if its a stupid idea. Brian
  5. You're right, but sometimes its less annoying to give them the answer, especially when a language barrier is in the way. Won't let it happen again. B
  6. I have a project down the road where I need to store Graph data in a relational database. I wanted to see what other people are doing in terms of table structure in a database to store graph data from various tests. The graphs could have a variable number of plots and also a variable number of points (say up to 1k pts) in each plot. Based on my limited experience with database design I was going to make 3 tables in the dB: Table 1 (PlotData) col 1 = PlotDataID, autonumber (primary key) integer col 2 = PlotID_fk, (foreign key) integer col 3 = PlotDataX, real col 4 = PlotDataY, real Table 2 (Plots) col 1 = PlotID_pk, autonumber (primary key) col 2 = GraphID_fk, (foreign key) integer col (n) = (plot info ....) col (n+1) = (other plot info) Table 3 (Graphs) col1 = GraphID_pk col(n) = ....(graph info) col(n+1) =...(some other graph info) Then JOIN them altogether on the primary keys to retrieve the data. My worry is PlotData table will get huge and take a long time to query. Has anyone gone down this road before? Is there a better way? Thanks in advance
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.