Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/18/2021 in all areas

  1. I am able to open the vip file from the VIPM but when I click on the desktop to install tha package nothing happens. It sees that the VIPM Helper is missing since the upgrade
    1 point
  2. I've started this thread as a discussion point, to foster ideas and maybe come up with something unique, because I completely agree with JKI that user interface design in LabVIEW is dated, restrictive and well overdue an overhaul. Since the conception of NXG (2013) I've been campaigning for user interface design that avoids using absolute pixels, because pixels are irrelevant in this era. A user viewing a LabVIEW front panel on a 1080p 32" monitor, a 1080p 14" laptop or a 1080p 8" device will currently all be shown the exact same user interface, because your LabVIEW window will be 1920x1080 pixels in all three cases. However the actual physical size of each control and indicator varies enormously because for each display the actual pixel real world size decreases as the screen gets smaller. The term PPI is used to represent pixel density, and in this example it varies from 69ppi to 538ppi. This isn't the best example, but we've all seen how websites scale/alter their presentation as the window physical size changes. For example, shutterfly.com on my 1440p mobile in landscape, versus on my 1080p laptop: Despite having more pixels on my phone, the displayed website has less content because the renderer understands that the pixels are much smaller, so to ease my eyes I need enlarged buttons to keep things readable, and also touch friendly - which is another desirable feature. Everything is scaled appropriately based on an understanding of the real world dimensions. Examples of real-world digital pixels are points, or picas, depending on your base units (mm or inches). And this is what I really want. The ability to design a UI in relation to real-world points, with rules that define how the UI will restructure itself for different panel widths. During the NXG development feedback phases I wrote pages on potential approaches, include "controls that are special VIs", where a component of the UI is something similar to an XControl - an active piece of code embedded in a front panel chunk that acts like a LabVIEW control. Without the complexity of XControls, it would be more of a Smart Control, designed with a view to making scalable elements of a UI easy to develop, with programmed behaviours when user interactions occur, and based on points, not pixels. They could work like classes, providing the ability to create a group of similar controls that override inherited behaviours from parent smart controls. I can image creating a colour palette within the abstract parent, and child smart controls for each component of the UI. Change the colours in the parent class and all the controls redraw with the new theme. They would each be an element of a UI, such as a menu banner or hamburger menu system, or simply a button. The interactions to them would likely be through messages, or user events, rather than terminals etc. I've not seen anything yet in LabVIEW that can provide this real-world sizing behaviour, and I don't expect it would be simple to develop (if possible at all), but I wonder if others have similar interests, or have achieved anything along these lines themselves?
    1 point
  3. Hi Jaun, To fix this, can you try running this exe as Administrator (it should ask you to run as Administrator when you double click it): "C:\Program Files (x86)\JKI\VI Package Manager\support\VIPM Update Registry.exe" Please let me know if that helps. -Jim
    1 point
  4. In any validation setting, the tolerances around measured and reported values is critical, and so is tracking the tolerances for any given parameter being measured, with any measurement device or sensor. To automate the calculation of these ranges and limits within our overall application, we must track the specifications of any of these parameters. This used to be done using a peer reviewed excel table, and was loaded into LabVIEW using the Report Generation Toolkit. This had several drawbacks, but that's not the point of this post. The point is that using Excel means that any text becomes free text and if data isn't entered correctly then it can cause issues with parsing. So I created something I call the Specification Manager. It's a small utility that is intended to only be used by validation test case developers to add new specifications to the database of available specifications that can be tested, or to add new hardware for use in the validation tool. I built this tool in about 2-3 days as a way of trying out the JKI Flat UI 2.0 and the Design Palette. Here's the home screen of the tool: Some things that I think make this a nice UI: Dark background (76, 76, 76) and a nice pop of vibrant color, the icon for the tool uses the same two colors to provide consistency All native windows elements are hidden as this tool is very small and simple, there's no need for a toolbar, etc. Our company uses Century Gothic as a common font in many places, so I used that for some of my UI elements (title bar, specifically) System Chiselled Line separating workflow components of the tool. That horizontal line doesn't look like much, but it's a visual separation of the two things you're supposed to do with this tool. 1) select a file path, 2) manipulate the individual .spec files Listbox to store data - I hate working with listboxes, but I think they are the best UI element for storing continuous data. They look way better than any array I've seen when the data is simple. To add a new specification to the library, you press 'add' and get a dialog window that's a sort of wizard: I used the JKI built-in buttons here to give some sort of icon to the various specifications that can be created. I also changed the color scheme of this wizard to 'light' to signal to the user that this is a dialog/configuration type window and not really part of the core functionality of the utility. If this were a project for a wider audience, I would have customized them a bit more, but as-is, I think it's okay. The symbols are kind of meaningless as the library isn't as vast as I'd like it to be. After selecting the type of specification, you enter the name of it: This screen continues to use consistent fonts, and buttons from the previous screen. Pressing 'Continue' gets you to the heart of what this application is intended to do, modify specifications. (*I typed in random data, please don't double check these against the actual specifications of the 6218 - I will not be using this data in production) I used an array of customized clusters containing the JKI Flat UI 2.0 numerics and enums, then used some more of their pre-built buttons at the bottom for continued navigation. I used the same pop of color on the cancel button, mostly for fun, but also as a way of drawing immediate contrast between the other two operations that the buttons provide. That's about it! This is an internal-only tool, but I think that editing specifications using this small purpose-built utility will be easier than us using Excel to do the same thing. Overall impressions of the Flat UI 2.0 library: Pros: good selection of commonly used buttons and controls, consistent theme across numerics, strings, enums, file paths, and buttons - makes a consistent UI easy to build Color customization of buttons is easy, including customization of the hover-state (which I did to the 'X' button on the home screen of the utility) Wishlist: As with any library of icons and UI elements - a wider selection. I had a hard time finding icons for my 'Add Specification' wizard screen and had to reach pretty far Design palette only launches when using the left ctrl+shift buttons, it'd be nice for it to work with either left or right Cons: Working with the String controls and indicators was a little strange. There are actually two resizable elements in a single control, one for the frame/background and one for the actual text field. I had to be careful when resizing the control to make sure that both fields were resized correctly. Also the front panel snapping meant that the border around the text area was easy to lose if the text field itself was resized incorrectly. I will probably continue to use the UI library for the internal only developer tools, but for the main applications that I'm working on there is still heavy customization specific to my company that I will continue to have to do. Thanks for reading - feel free to ask any questions about the design choices or other elements of the UI for this tool.
    1 point
×
×
  • Create New...

Important Information

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