jaegen

QUOTE(Aristos Queue @ Jul 10 2007, 03:18 PM) Perhaps NI needs to provide a bug reproducibility toolkit Honestly, that's the only thing that ever stops me from reporting a bug. When you're working on a project with 2000 VIs, and the bug appears to involve dynamically registered events, timed while loops, call-by-reference, sub-panels, UI thread issues, strange MS Windows interactions, and the phase of the moon, trying to create a pared-down VI that reproduces the bug is usually much more work than finding a workaround - especially if it only appears in a built executable. Thanks for the voluntary bug report though - I'm much, much more pleased with the disclosure than I am disappointed about the existence of a bug. Jaegen

QUOTE(Michael_Aivaliotis @ Jul 10 2007, 02:21 AM) Yes, this applies to any control, but if you have a graph in an XControl it's especially bad, because only the data changes are plotted - if the same value is written twice, only one point is plotted on the graph. Jaegen

Just FYI - there are some real issues with using a graph inside an XControl. See here ("Data Change" only fires if different data is written to the terminal, not every time any data is written to the terminal) Jaegen

My $0.02CDN: In cases where the type def needs to be cosmetic, we simply make it strict, and make all the cosmetic changes to the type def itself (this is a bit of a hassle when you need things to line up with other type defs etc., but it seems to be the best option). We have a few cases where we need the type def to be non-strict (we need to do some cosmetic changes programmatically). In these cases, when we need to make changes to the type def we follow these steps: 1. Open the GUI VI 2. Open the type def 3. Make the type def strict 4. Make the changes 5. Save and close the type def 6. Open the type def again 7. Make the type def non-strict 8. Save and close the type def 9. Save the GUI VI This way the cosmetic changes and the data changes get propogated. Note that this only works for a single cosmetic instance. If you need more than one (different looking) instance of the same data, I think the best way is either to disconnect from the type def, or use two different strict type defs which contain the same data. Jaegen

QUOTE(Michael_Aivaliotis @ May 29 2007, 08:34 PM) So I guess I'll be at the Hilton then ... Jaegen

Well, since I'm an NI-Week rookie, I figured I'd tap the LAVA brain trust before picking a hotel. Does anyone have strong feelings about a particular hotel? Thanks, Jaegen

Me too! Jaegen

Great article! If only you'd written it 3 years ago ... QUOTE Have you (or anyone else) made such a tool??? Jaegen

:beer: :beer: :beer: :beer: :beer: :beer: :beer: Finally!! Looks like Stephen won't be paying for :beer: this year. Jaegen

Thanks Jim for all the help and LabVIEW-friendly energy. Jaegen

Well, apparently this is a bug, but not the one I thought. "Ignore Errors inside Node" does not work properly in 7.1. See the NI thread for details. Jaegen

After trying to work out how to do this for most of the day, I'm giving up and asking for help (which I should have done in the first place). I would like to display the Subversion revision info (Rev #, Last Commit Date, etc.) in a built LV application's "About" window. Does anyone have advice on how best to do this? I'm keen on using the "SubWCRev" command-line utility that comes with TortoiseSVN, since it will indicate whether the working copy has uncommitted mods (i.e. I'd like to append a "*" character to the Rev # in this case), but if there's an easier way to do it I'm all ears. Any advice would be greatly appreciated. Jaegen

[i posted this on the NI forums and haven't gotten any response ... probably should have just started here ] I've actually checked this in LV 7.1.1 and 8.5 - I don't have easy access to anything in between at the moment (it's been posted as a bug for 8.5). There appears to be a bug with the "VI Modifications Bitset" property: 1. In the attached llb, open "main.vi" 2. Open "Cluster" for editing (it's a type def) 3. Open "Sub1" for editing, and make a change to it (move a control slightly) 4. In the attached llb, open "ModsBitsetBug.vi", look at the block diagram, then run it 5. Notice that the "Mods.VI" property returns a different value for the type defs depending on whether it is above or below "Mods.Block Diagram" Here's what I get: And here's what the diagram looks like: http://forums.lavag.org/index.php?act=attach&type=post&id=5383 Jaegen

QUOTE(Michael_Aivaliotis @ Mar 12 2007, 05:02 PM) Thanks Michael, that's exactly what I ended up doing. The only reason I brought this up was that it seems inconsistent to me to allow modification of the text colour at development time (via the font drop-down), but not programmatically. The other issue that may rear its ugly head is this (normal controls suddenly become "system" controls if you've used a "system" element in them and try to open in a later version of LV). Jaegen

http://sourceforge.net/projects/id3lib/ The windows binaries download contains a dll. No idea how to use it, but it should work. Jaegen

Hello, I understand/accept that certain properties of the "Dialog" style controls are not modifiable. However, with a "Dialog Table", I can modify the colour of the text in a cell using the font drop-down box, but the "Cell BG Color" property doesn't work programmatically. Anyone know how I can do this? Is there no way of getting a reference to an individual cell, or its text properties? Thanks, Jaegen

I applied several months ago, but haven't heard any response. I'm very keen to get at this - should I apply again? Jaegen

QUOTE(jaegen @ Feb 8 2007, 10:58 AM) OK, by "anyone" I suppose I meant Darren/Aristos etc. or anyone else who has access to the source code . Is this worthy of a bug report? Jaegen

Hello, I recently witnessed some strange behaviour in the performance of the "Unflatten From XML" function. When unflattening an array of strings, the contents of the string have a huge impact on how quickly the function works. It seems that if the array contains strings containing at least one space character, the function runs more than 100 times faster. I've attached a VI which demonstrates this. When I run this VI with nothing in the "String" control (this is the default), the unflatten takes ~2000 ms. If the "String" control contains just a space character, it takes 16 ms! If it contains any combination of characters with no spaces, it still takes more than 2000 ms. If it contains any combination of characters with at least on space, it goes back to less than 20 ms. Anyone have any idea why this is the case? Jaegen Download File:post-932-1170961059.vi

See here. Jaegen

Jack, Here is a pretty good workaround (putting a small decoration on top of any part of the table corrects the bug). Jaegen

Kevin, It's possible to "edit" the scale on a gauge to make the gap between min and max 0 pixels. Just hold the mouse over the min or max tick mark, and the cursor should change to a semi-circular shape. Click and drag, and you can drag min and max together. I've attached an example. Jaegen EDIT: Looks like Gary beat me by 1 minute :laugh: Download File:post-932-1165602607.vi

Sorry CRoebuck, I just found these ads on YouTube and had to share them - some of the funniest I've ever seen: I'm sure crelf, being a premium member, will be only too happy to embed them ... Jaegen

I wondered how long it would take for this to come up here. It's like the Godwin's Law of Australia-England relations. Jaegen

Unfortunately this won't work properly if you have 2 sub-clusters which are identical (i.e. 2 instances of a type def) or which contain an element with the same name. The problem is that if you have an unwired unbundle containing the name of just the low-level element you want, and you wire it to the top-level cluster, LV will always assume you want the first instance of that name, not any subsequent ones (it's not LV's fault - it doesn't really have any way of knowing which sub-cluster you want to drill into). I'm probably not explaining this clearly - check out the attached VI. Delete the first unbundle and wire the second one directly to the control - it will always revert to "Sub 1.Num 1", not "Sub 2.Num 1". Jaegen Download File:post-932-1164820867.vi