Jump to content

Thoric

Members
  • Posts

    39
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Thoric

  1. Turns out this was down to a particular setting in my "ini" file that creates a full NI dump file if a problem occurs, which I added when testing Beta releases of VIPM. So for the vast majority of people, this will never be a problem.
  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?
  3. In our framework, we solve this with a VI that contains purely the hamburger items on its Front Panel. It is launched by the main GUI when the Hamburger Menu icon is selected, and positioned directly over the hamburger menu icon. If you select an item it closes itself and returns a message to the caller with information on what was clicked. If you click away from it, it closes without a message. I can't share code because our framework uses actors, and without the supporting infrastructure of the whole architecture you'd not be able to use it anyway. BUt you don't need to use actors to solve this, just ordinary VIs. Ensure you set the HamburgerMenu.vi display properties to exclude the title, menu, scrollbars etc., and is set to Floating so that it doesn't fall behind the main GUI VI.
  4. Please note your query is regarding the Design Palette. This forum is actually about user interface design, as per the header text. Consider reposting your question in the Design Palette forum, or read this posting which discusses your exact query:
  5. Just creating a quick note because I couldn't see anything relating to this online. Today I was recovering space on my laptop and found that the "LabVIEW Data\LVInternalReports\VI Package Manager" folder was sitting at 35GB. By far the largest folder of sacrificial material I could find. My dev machine only has 250GB SSD so this was hurting me bad. Perhaps in future releases it can be automatically cleansed by VIPM when the files reach a certain age?
  6. So I often leave VIP builder open when I'm working on a package that's being rebuilt multiple times whilst I work out bugs and issues. If I leave VIP Builder open overnight on my PC (Windows 7 SP1) then the following morning, as soon as I edit the Build Specification and click Save I get a cyclical error code 1 that I cannot close and I'm forced to kill VIPM.
×
×
  • Create New...

Important Information

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