Jump to content

jaegen

Members
  • Posts

    152
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by jaegen

  1. Some further info: Rather than "manually" getting a reference to all those controls, you might want to look into using the "Controls[]" property for your VI's front panel: Of course, since you probably don't want to disable everything, you'll need some logic around when to write a "2" and when to write a "0". Also, it's probably more efficient to get all the references at startup, and store them in a shift register or something, rather than building your great big array every time the event fires. Good luck, Jaegen
  2. LV 8.2 actually has a "FrontPanel.Monitor" property for VIs which should make this even easier. Jaegen
  3. Very clever - I'd given up on this being possible at all (not that this is really a realistic solution though). Joking about bug reports aside, perhaps we need someone with access to the "source code" to at least give some insight into this ... Jaegen
  4. Shoot, there goes my theory that it actually had something to do with German vs. English, or ANSI vs. Unicode, or the like. I thought of this, but I don't think there's a way to do this that handles everything - it has to do with the way LabVIEW handles resizes of an unbundle node in general. If you wire an unbundle by name and drag down, it automatically fills with all of the elements in the cluster, but doesn't drill down into sub clusters until you get to the end (i.e. if your last element is a sub cluster, then it starts automatically filling with the elements of that cluster - I'd love it if they changed this by the way). So, with scripting you could work out a way to get into the last sub cluster, but not any others. Are you guys sure that you actually had this working? The end result is very dependent on which values are in the unbundle before you run, and which values you're asking for. Another annoying thing is that it doesn't return an error if you ask for something that doesn't exist. Should I file a bug report for this??? (Or is scripting in its entirety a "bug" in NI's world ). Jaegen
  5. Well ... there's source code and there's "source code" Jaegen
  6. Is this the first ever appearance of actual LabVIEW "source code"??? Jaegen
  7. Hmmm, maybe it only works in the German language version. Here's what I get: (I made some minor mods to make mine look like yours) Note: I'm using LV 7.1.1 (though it doesn't seem to work in 8.2 as well) Jaegen
  8. It's also in "Programming" - "Graphics & Sound" - "Picture Functions" ... Also, one of the OpenG packages (the dynamic palette one I think) gives you the old 7.1 style palette even in 8.x. Also, if you "pin" the palette (so it stays visible), you can right click on anything and select "Add Item to Favo(u)rites". All this being said, I fully agree - this change did nothing but annoy. Jaegen
  9. I believe this is exactly what you're looking for. Jaegen
  10. I understand you can't supply a date, but can you tell us whether or not you personally know the date? (i.e. Are things far enough along for there to actually be a "date"?) Jaegen
  11. I would certainly be all for this ... Of course, I'd love a few other things too: 1. It would be nice to somehow be able to retain formatting (or at least resizing/autosizing) of type def constants. It's really annoying when you make a simple change and suddenly the constant extends up and down off the screen. I almost never use constants for cluster type defs because of this. Could you add a block diagram to the control editor for strict type defs, and have this allow cosmetic editing of the type def's constant representation??? 2. It would also be nice to have non-contiguous enum elements - but I understand this would probably be rather difficult to implement at this stage of the game. 3. Have some means of having a strict type def which is actually just an "instance" of a non-strict type def, or at least some way of keeping cosmetic edits made to a non-strict type def instance. I often have the situation where I want to put a type def on the front panel, so it has to be nice and pretty, but I'd rather have all the cases where I'm just using the type def for its data not take up so much space. Currently the only options are: Make the type def non-strict and simple, pretty-up the front panel instance, and have changes to the type def totally kill all of your prettying Make the type def strict and prettied-up, and use this everywhere (even though it's overkill and makes it hard to have tidy sub-VI front panels). Make the type def non-strict (or strict, but only to keep it small and simple everywhere), and don't use the type-def at all for the pretty version (Dangerous! Type def changes don't get propogated at all). I just realized that perhaps XControls provide a way around this - I'll have to look into that (I'm a little concerned about XControl overhead just to achieve this though) Jaegen
  12. jaegen

    "LabVIEW"

    Sounds like a perfect name for an open source clone, once all NI's patents expire :laugh: Though it'll probably get named KabVIEW, or GabVIEW, or XView, ... or JKIVIEW
  13. Of the top of my head, there's probably some way you could string together 2 (or more) charts. Just line them up properly, make the appropriate parts transparent, and workout how to set the scale ranges. Jaegen
  14. jaegen

    "LabVIEW"

    Ah, but you've just broken the rule that is the whole point of this thread :thumbdown: It needs to be Lab\/13W Jaegen
  15. But couldn't you create a "generic" cluster with unnamed members, and wire that into the middle of the bundle function? This way the names would get "erased". This has its disadvantages of course (you need to create and maintain this "generic" cluster). Actually, now that I look at this, here is a better solution: But note that the type cast won't work if you have strings or arrays in your cluster. Jaegen
  16. It's not April 1st is it??? :laugh: Jaegen
  17. jaegen

    "LabVIEW"

    ... "Queen of Canada" always sounds a little silly to me ... Jaegen
  18. Well, if you really haven't had any problems with IE, and you've tried FF and didn't like it (or had problems with it), then of course there is no technical reason to switch ... so I'll give you a philisophical one: Last time I checked, FF was just cresting the 10% mark in browser useage worldwide, with IE at ~89%. In my experience, any time a company/product has that much of a monopoly, consumers lose. In fact, you could argue that we all know this first-hand, given the monopoly NI has on graphical programming; Why are we here and not over at the NI forums??? (Disclaimer: I, too, am not bashing LV here - just pointing out that it's not perfect, and some of its imperfections are allowed to remain due to the lack of competition). IE hasn't been updated for 5 years! Do you really believe any software application should last that long? So use FF to make the world a better place, if nothing else. Jaegen
  19. I could've sworn I checked this :headbang: It's a bit confusing though, because while this method gives you a drop-down list filled with all modified VIs, if you attempt to close a modified subVI, then click "Explain Changes ...", the drop down only includes the current VI. Either way, I like my little tool Thanks - I haven't looked at this yet, but it may come in handy. Jaegen
  20. Sorry if this has been asked/answered before - I've searched as much as I can (see here for how not to design a forum search engine ) I would like to be able to get the list of modified VIs that shows up when you click the "Explain Changes..." button on the "Save changes?" dialog box, without having to close the top-level VI. Anyone know how to do this? I guess I could script something to traverse all the VIs in memory and check their "Current Changes", but I'd rather not have to. Thanks, Jaegen ... Well, apparently it takes about 1/2 an hour to script this up (not starting completely from scratch of course). Notes: Saved in LV7.1.1 If you don't have OpenG stuff installed, just delete the second sequence frame and the results won't be sorted If you double-click on a row, the VI will be opened This may not work properly in LV8 and higher, since the "All VIs in Memory" propery only returns VIs in the current application instance Does anyone know what the mod codes actually mean? Download File:post-932-1162413902.vi
  21. jaegen

    Bush Vs Bush

    Ahhhh, where would we be without The Daily Show???
  22. This site is now even more dated. Has anyone updated a personal version of this? Could we move/copy it here (LAVA) and update it collaboratively? Jaegen
  23. This is along the lines of what I was thinking about. Of course, do we want to turn LV into a text-based language? And Michael's idea would have to somehow get around these issues (yes, blatant plug for posts of mine that no one's responded to yet ). I was also thinking something that ventured into somehow decoding the VI file format would be cool (Word and Excel support in OpenOffice.org got me thinking), but I really have no idea whether this is at all possible/practical. Jaegen
  24. Ahh ... of course - another classic. :thumbup:
  25. ... somebody doesn't remember their cheesy 80s music - It's Whitney Houston, not Lionel. Jaegen
×
×
  • Create New...

Important Information

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