Jump to content

Steen Schmidt

  • Content Count

  • Joined

  • Last visited

  • Days Won


Steen Schmidt last won the day on January 25 2015

Steen Schmidt had the most liked content!

Community Reputation


About Steen Schmidt

  • Rank
    Very Active
  • Birthday 04/29/1976

Profile Information

  • Gender
  • Location

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2014
  • Since

Recent Profile Visitors

1,734 profile views
  1. Oh yes, that's a side effect of VIPM not making sure all dependencies are in order during the installation process. You want to either 1) uninstall and then re-install Expression Parser after its dependencies are in place (making sure mass compile is enabled in VIPM), or 2) manually mass compile the 'C:\Program Files (x86)\National Instruments\LabVIEW 2015\vi.lib\GPower\ExprParser' folder, whichever you prefer. All something VIPM should have done for you. The reason is that since you have updated a dependency (VI Register) after you installed Expression Parser it makes LabVIEW need to com
  2. You need to upgrade the VI Register toolset to v2016.0.0.31. VIPM should have told you this (since that is a dependency of Expression Parser), but VIPM has been broken for a long while on many details. You can get VI Register v2016.0.0.31 either through VIPM (it's published on the LabVIEW Tools Network) or from our website here: http://www.gpower.as/images/downloads/viregister/gpower_lib_viregister-2016.0.0.31.vipc Cheers, Steen
  3. We have had such a toolset for a couple of years: http://www.gpower.as/downloads/expression-parser-toolset I have worked for almost 15 years writing math software for HP calculators, so I'm also keen on RPN ;-) It's not trivial to do a fully functional toolset like Expression Parser. Probably close to 1000 hours have gone into making it. From our website: Evaluate mathematical expressions, given as text strings, into numeric values: Build and change your math expressions at runtime. More than 260 math functions and constants supported. Very high performanc
  4. We investigated doing a non-LabVIEW UI for a recent project, due to alle the reasons Shaun lists, but LabVIEW web service support was simply too lacking (crippled web server and non-existent security). So, lot's of good reasons to do it, just not really possible in a comfortable way.
  5. Thanks, but having N control P's, one on top of each control T, was what I'd like to avoid. I would much prefer a single control P that resized and moved in place over each control T whenever it was needed. The reasons for this: 1) Being able to drop just a single "Drop Sink" (I call the control P that) control anywhere on the FP is simpler than meticuously placing N of them over each control T (and leaving enough border of the underlying control T to keep its Mouse Over/Mouse Leave events actionable). 2) The hidden control Ps won't scale and move with the FP, unless you jump through
  6. No no, that's perfectly fine. I may come of as too complaintive. At other times I'm a fierce defendant of LabVIEW :-) It might be a question of circumstances for me - I enjoy programming LabVIEW, so if I have the time to do it I don't mind challenging workarounds. If I'm short on time I hate I have to do them. And also, things might get better in the future. So don't put too much weight on my complaining, my bark is much worse than my bite :-) Yes, exactly the workaround I want to implement. But it's not so simple. I don't want the invisible path control (let's call this Control P) to
  7. I'm interested as well, I think we've come to the end regarding gifs anyway, haven't we? But for future searchability we could start a new thread...
  8. Wow, this is frightening to look at from the outside: All I wanted was for LabVIEW to play my animated gif correctly, a feature it's supposed to have built in. That didn't work with my gif (nor Michael's it seems), and no sensible error message comes out of LabVIEW. And now you guys are discussing embedding web browsers in ActiveX containers, and programming a gif decoder and playback feature manually, the latter even as an XControl. And all that with a straight face. We're so used to LabVIEW falling short and us solving simple shortcomings with days of programming, that we
  9. Not like that. This requirement is: 1. Illustrate busy state on the window. 2. When the window is not busy, the busy indicator must be visible but subdued (to familiarize users with the location of the busy indicator). Just like in VIPM for instance: One simple way to do that was with a toggle-button that has a static subdued image in False state, and a spinner gif in True state. Then activating "busy" is simply programmatically setting the button to True. It's not so the user can push that button.
  10. Probably won't get added to LabVIEW: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-drag-and-drop-support-for-OS-files-on-any-control/idi-p/1073586
  11. Ok, not going to happen. I try to use http://ezgif.com/maker, which is a great site for making and editing animated images, but LabVIEW just gives me this on the created files:
  12. Yes, I want to do some loaders/spinners. I wanted the gif on a button to easily switch between inactive (a static subdued image) and active (the animated gif) states. I started on the route to populate either a ring or a 1D array with the images, and then make a brat VI to automate animation of it. Then I thought better of it; "this is LabVIEW again forcing me to jump through hoops and spend numerous hours on something that should just be a drop-in". I simply won't do any of these work arounds to get a freaking animated gif to roll. But LabVIEW isn't alone here, animated gif support is al
  13. Just ran into this today. Wanted to use the attached animated gif, but it runs really slow on a FP (as state image on a button actually). Oh well, just one of those things. I bet one of those images from 1985 will work just fine. You know, black/white 16x16 px, 4 frames, 1 second in-between frames, no transparency... EDIT: I did try one of those gif speedup services (ezgif.com), and the new gif animates much faster, except in LabVIEW where it continues to crawl along. It must be an issue of LabVIEW throttling resources to run the gif. I can see how such a gif could easily
  14. Yes at runtime. But dynamic dispatch isn't a phenomenon at edit time, only the type resolving (which doesn't have to force load of all VIs in the class). So my question remains; what is the reason behind classes having to load all their member VIs in the editor? Since classes are basically a type, it is probably to avoid edit racing like with typedefs (two people simultaneously editing two members, afterwards both edits need to update the same class lib resulting in a non-resolvable conflict).
  15. One reason might be that to read the linker info you'll have to traverse the entire lib tree. Since refnums to all libs in the tree after this are now in memory, they are left in memory. Perhaps under the assumption that stuff within that tree is soon to be called, and thus it's assumed more efficient to leave them in memory than to close them again? The libraries themselves aren't that heavy, but quick access to the linker info will give you a more responsive IDE. The better question is why do classes have to load all their VIs? XControls have to because they execute, but class execution
  • Create New...

Important Information

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