Tip strip by user-events

[Paul_Torek]

OK, this isn't as cool as Brian's FGV wrapper.  But I implemented Becky's suggestion for a designated help area (indicator) on a GUI.  I used NI's template for User Interface Event Handler as the starting point.  Except, as Dan advised, I got rid of the stop button; you just use the red X in the upper right corner (or whatever your non-Windows equivalent is).  There is (in the development environment) a button which auto-generates a text file containing the name of every control in column A and the description in column B.  You supply the description in a pop-up GUI-within-the-GUI.

[Hooovahh]

Very neat.  I saw a few improvements, and code duplication going on, particularly if you have OpenG installed.  Attatched is my edit to your version which only has two VIs instead of the 15 yours had.  Here's a few tips on the changes I made.

• I used the system string control for the tip
• I made panes on the main UI and fit the tip indicator to the lower pane
• I change window settings to dialog so the menu bar and toolbar weren't seen (turned off modal)
• I used the conditional disable to detect if we are in the runtime
• If you did use the application property node you don't need to wire the reference.  When unwired it uses the current application instance, just like a unwired VI type on a property node assumes "This VI".  This means there is no need to open and close the application reference.
• Get calling VI file name using property node name
• Stip file extentions using OpenG, or the native Get File Extension
• Parent calling directory using OpenG
• Create Dir if not exist using OpenG
• We can hide the main UI then show it again using the VI reference, this makes it so the user can't go back to the other UI
• Added OK and Cancel to the edit dialog, close usually means cancel and having it apply changes seemed strange
• Read file using read from spreadsheet file
• Delete from array can return the last element in an array

I'm not trying to be critical I just saw some room for improvment and I think you weren't aware of some of these.  If you aren't allowed to use OpenG then half of these don't really apply.

[Paul_Torek]

Cool, thanks.  A lot of subVIs were written before I discovered OpenG or before they added the same feature, and I just got in the habit of using my own.  I need to edit my Palette set to put OpenG array in the array palette, etc., and then delete my redundant VIs. 

The read_spreadsheet_file however, I typically use instead of the standard because mine tells which file was sought when the file is not found.  But here, I'm cancelling error 7 anyway, so might as well use the NI one.

So that's what a conditional disable is for.  Shoulda paid more attention I guess.

[Hooovahh]

Paul_Torek wrote:

So that's what a conditional disable is for.  Shoulda paid more attention I guess.

Oh it can do a few other things too, but I'd say this is the majority of the cases I've seen it used.  It can also be used to detect if the VI is running on real time, or if it is 64 bit LabVIEW.

Another use is to set custom symbols in the project, and then you can have code disabled or enabled based on those values.

[Paul_Torek]

Minor details: in your edit of the tip_editor, the directions need to change in accordance with the new functionality.  I.e., just closing the window using the red X now amounts to Cancel rather than OK.  Also, if you plan to use this as a template (I do), adding an Open/Create File and Close File just before Read Spreadsheet String will avoid a needless error message, when you've Saved-As this VI under a new name and don't yet have a tips file for it.

After a test drive, I really appreciate your changes.

[Hooovahh]

Paul_Torek wrote:

Also, if you plan to use this as a template (I do), adding an Open/Create File and Close File just before Read Spreadsheet String will avoid a needless error message, when you've Saved-As this VI under a new name and don't yet have a tips file for it.

Yeah I ran the VI the first time and this happened, so I thought about fixing it, but I figured for the example I'm just going to include the text file in the zip so I didn't bother.  Glad you liked the changes, and thanks for the initial post.  We've yet to hear from Becky herself telling us how close we are to her implementation.

[JLMommy]

I started developing my UI template a few years ago as a way to learn/practice GOOP.  I also wanted to figure out how to make my own "Project Template".   I thought about paring it down and just showing how I do the "info" bar, but decided some of you may benefit from the whole architecture.  There is definitely room for improvement, but its at least a start.  I know there is a lot more I could/should do with the subpanels.

Install ui_command_manager-1.1.2.16.vip first.  This is an API for user interface manipulation.  There are commands for updating the

help (info on lower left) and status indicators, enabling/disabling controls, loading subpanels, setting cursor busy/unbusy, sliding

panes to show/hide menus, etc. 

Next, install ui_cmd_mgr_project_template-1.1.2.6.vip.  This will install the Project Template into the LabVIEW framework.  After it is installed, you'll be able to select "Create Project" and select UI Command Manager.  This will walk you through the wizard and create a project with a single VI - User Interface (Main):

Most of the buttons have 'captions' - if not, "No Help Available" appears in the lower left.  The lower right is for status updates.  If you press the save button, you'll see the cursor go busy and the status will update to "Saving...".  Nothing is actually happening - its just an example of  how it works.  Hovering over the left splitter will cause the toolbar to move in/out.  Pressing the calendar button will load a subpanel that shows the date/time.  Clicking OK or Cancel in the subpanel will remove it.  The other buttons aren't set up to do anything.

FYI - The last set of source I had saved off and built packages in was LV2012.  I just tested it in 2014 and it works fine.  I'm not sure how much help/documentation I stuck in there.  I know the project template documentation was copied over from one of the NI samples and I didn't update it. 

If you want to see how each command is implemented, open the UI Command Manager.lvlib that is installed to vi lib.  Each command is a child class of the UI Command Manager class.  Within each command class there is a ui_Execute VI that is dynamically dispatched.  This VI containes the 'guts'.

Enjoy!  Let me know what you all think! 

- Becky