Jump to content

Thoric

Members
  • Posts

    42
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Thoric

  1. Update: I tried moving every class into a dud library, saving every class, then moved them all back out to where they were originally, saved every class, then tried VI Package Builder, and.... Success!! So not sure what this did but changing the ownership of classes from independent to belonging-to-a-library and then back again seemed to sort this.
  2. Update: Deleting the mutation history didn't resolve this error.
  3. I'm using Package Builder to create our framework package and have encountered this error several times before. It always happens when I change the name of a class in LabVIEW. For example, in this instance I changed a class from "ATEF_Base_Actor.lvclass" to "ATEF_v1_Base_Actor.lvclass", and subsequently the builder fails with an error: Method Name: Linker:Read Info From File The file at 'C:\Projects\ATE LabVIEW Framework\src\.ATE Framework\Core ATEF Actors\ATEF_v1_Base_Actor\ATEF_v1_Base_Actor.lvclass\ATEF_v1_Base_Actor.ctl' was expected to have the qualified name 'ATEF_v1_Base_Actor.lvclass:ATEF_v1_Base_Actor.ctl', but has the qualified name 'ATEF_Base_Actor.lvclass:ATEF_v1_Base_Actor.ctl'. Somehow VI Package Builder is able to recognise the original class name from some linker info. I wonder if this is legacy data in the class itself? A string search of the .lvclass file XML does not reveal any "ATEF_Base_Actor" results, but the error relates to the private data ".ctl". In LabVIEW itself the private data control has no legacy class name references: I've tried Mass Compile, I've tried deleting the compiler cache, I've tried restarting LabVIEW. In the past, the only solution has been to revert in source code control and avoid renaming classes at all, but I need this working now. Does anyone have an idea how this is happening? Is there a bug in LabVIEW that's maintaining some stale linker data in the class somehow? I vaguely recall there's a method to purge class historical data (mutation history), do I need to try this? Also, we standardised on LabVIEW 2017 SP1 and VI Package Manager 2017 (seems we're on v17.0.0), and we can't upgrade to new major releases.
  4. 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.
  5. 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?
  6. 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.
  7. 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:
  8. 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?
  9. The lack of a Pro license for that version. My place of work has only VIPM 2017 Pro licenses because that's the year we standardised on for our development work (since 2017). A major update may be on the cards, but it's an exhausting effort we're putting off as long as possible.
  10. Quick reply: The toolkit is a class for creating AWS Version 4 signatures and handling REST API method calls (there were some things missing from the NI offering, so I wrote my own). The tool includes a dependency to JSONtext which includes a VIM which confused VIPB 2017, the version I'm currently building re-use code within. I understand the VIM issue was resolved in VIPB 2020. So although I wanted to create a VIP, it's a PPL currently. Versioned, distributed manually to projects and included in a non-version-controlled support folder (a bit like lv-venv!) alongside the source. I manually add the lvlibp file to the Project as an item so that it's loaded and available through QuickDrop.
  11. Therefore I take it that it's "Once a dragon master, always a dragon master". No dipping back into the old ways. Thanks Jim.
  12. I have an unusual thought, which I'm close to dismissing but penning here in case it has merit and warrants further conversation. I have a reuse toolkit that can't be built by VI Package Builder (compatibility issues with VIPB 2017 and VIMs) so it's currently a packed library lvlibp. It's technically a toolkit of VIs, but without a palette (I would like it to have a palette). It's similar to a package, as per VIP qualification, because: It's a package of VIs to be called by the Project It ought to be installed into the LabVIEW IDE and not the project source code folder It has no need to be included in SCC So I wondered if it could be installed into lv-venv? Maybe a custom subfolder, ideally managed by Dragon too. Doing this makes it local (virtualised) and project specific. Allows me to use future versions on future projects without interfering with existing projects. Avoids including it in the project source code folder and hence also SCC. I think also it might be good to have it, optionally, appear in the Project view under a virtual folder, perhaps labelled "Custom Virtualised Dependencies", so that the VIs are included in the Project and hence Quick Drop etc. Just wondering what others think. Happy to be told I'm just dreaming 😄
  13. I have a multitude of existing projects on my laptop which use a lot of globally installed packages, that need to remain globally installed. In the future, by creating a Dragon-style lv-venv project with virtualised packages, will having the same packages installed both globally and virtualised locally present a problem?
  14. I wonder if a quick enforced refresh of the Project window would kick this. Perhaps a single pixel window resize to trick it into redrawing?
  15. Not a virtual machine, a pretty simple set up here. Windows 10 Pro directly on a DELL Precision laptop
  16. Whenever I open a Project in Dragon, or switch from another tab (such as Resources) back to the Project view, the LabVIEW Menu Bar is corrupt. It seems to somehow keep a portion of the previous view, so sometimes it's text or just white space: My machine: Windows 10 Pro 10.0.18363 build 18363 64 bit LabVIEW 2018 SP1 Full Development System
  17. I have a development flow that involves a lot of repetitive muscle-memory actions, for example I frequently press CTRL+S (and CTRL+Shift+S) to ensure all is saved, because LabVIEW has, well, a predilection for going AWOL after saving VIs but before saving classes, resulting in nasty chaos. Traditionally, when I open, edit and then close a VI I've been working on the Project becomes the focus area once more, but that flow has been interrupted by Dragon it seems, which steals the focus and swallows up my keypresses. Dragon has assimilated the Project window and it doesn't seem to be passing through any shortcut keypresses? This includes simple things like pressing Up and Down to move the selected item, and more importantly: Navigating the Project items view with cursor keys, and using Return to open files CTRL+S to save the Project lvproj file, Shift+S to save all CTRL+E to switch the Project tree from Items to Paths Is there a way to ensure that all keypresses are passed through, or that when returning to Dragon from an open VI the LabVIEW Project remains the focus? I see that I can click deadspace somewhere the Project window and it highlights the LabVIEW project area, then my keypresses work again, but it doesn't come back when you return from editing code, and this is a distraction from my usual working flow, (I'm old and set in my ways, so it's something I'll probably forget to do and it needs to remain a subconscious muscle-memory action). Maybe I just need to get used to the difference, but the lack of pass-through hints at room for improvement with the integration of the Project window perhaps. Maybe a way to Undock the Project Window so that it's separate once again?
  18. I installed Project Dragon Beta (finally, I'm late to the party) and opened an existing lvproj. Dragon presented me with this window: It was only out of pure curiosity that I tried clicking the window edge to see if it resizes and suddenly a vertical scrollbar appears revealing that there are fields below the bottom of the window that I didn't know were there: Either be sure to show the scrollbar, or make this window taller to ensure the entire pane is visible 🙂
×
×
  • Create New...

Important Information

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