Yair

This is almost always caused by font changes between systems (e.g. if you use the system font or application font, which would be different between XP and 7). It probably only affects some of the controls because the different controls have different fonts.

Try setting the controls to a specific font to see if this stops happening. Alternatively, make sure that LabVIEW.ini and your app's INI file have the same AppFont and SysFont (or whatever they're called) lines.

Did you try searching for it online? It should be on NI's site and I believe it was updated at some point (so if you're currently working on LV 5, you might have to look in order to find an old version, or you could try asking someone at NI's version conversion board to convert it back for you).

When I look at the things like this I always prefer the quote of Einstein, "If I have seen farther than other men, it is because I have stood on the shoulder of giants."

Actually, it's attributed to Newton, who use a capital G in "Giants", supposedly to insult the person he sent the letter to, who was short, but that's apparently just a myth - http://www.isaacnewton.org.uk/essays/Giants . The actual idiom is older than that.

I gave about 90 seconds of brainpower to thinking about writing some sort of tracker that runs in parallel, but I'm not at all experienced with VI Scripting and it made my brain hurt to try to track each and every case in every open VI.

Ignoring what the others have said, you don't actually need to track multiple VIs. The secret is the VI Activation event, which tells you which VI you're now interacting with. You then only need to monitor the case structures in that VI (by polling, since I don't know of any events you can currently get for editing actions). The traverse for refs VI should be your friend and you might be able to use the private UID property to track the specific structures.

Here's a quick mod of the template I normally use for quick scripting actions on other VIs (which is itself just a pretty quick mod of Norm's code), where I added the relevant pieces (although I only added it in the action event, whereas you would want it in the timeout, and I didn't check it at all, so the class name might be wrong, or the UID property might not work, etc., and of course, I didn't add the actual tracking code).

Scripting.vit

Maybe it's my Big Brother-mandated browser settings or something.

Or that...   / / /

It works fine for me too on FF (although in the past there were multiple occasions where I saw something similar where the link would just go to the start of thread, but that was probably an issue with the forum software. There are probably a couple of threads here on that topic).

(BTW, it turned out that the source would not compile because of a typo, so simple but difficult to locate for a person unfamiliar with LabView develoment that it seems to be deliberate.  )

It might actually be much harder for someone who's familiar mainly with LabVIEW, as LV doesn't have the concept of typos breaking the compilation. Essentially, it's impossible to create such a problem in LV, so you would have to be aware of other languages to realize that could be a problem.

"Maybe Hoovah is really Crelf's alter-ego, which he uses to irk people?"

As if he doesn't have the ability to do that without needing an alter-ego...

OK, so I sampled a few services (which I was really hoping I wouldn't have to do) and here are my comments so far:

1. Pulse is a no go. Either I'm really stupid or it should never have been on the list I linked to. As far as I can tell, you can't give it RSS feeds - you can only select topics and it will decide what it wants to show you. Also, it doesn't seem to have a list display, only various types of grids.
2. I would be happy to test FeedReader if only it didn't insist that my CAPTCHAs are wrong when I try to register. Every single time. And I tried on two different browsers. If people here didn't recommend it I would probably have labeled it as a CAPTCHA farm.
3. Netvibes is more reasonable. It took me a bit of fiddling around to set up the UI, but I managed to. It has some nice features which Reader doesn't have, such as a better ability to process items in list view (you can select all, then uncheck some and mark only the selected as read, which could be useful to me). A couple of big disadvantages I ran into (which might have solutions, but I couldn't find them) are:
   1. It seems to update much slower than Reader. That might be less of an issue, because it's RSS, but it still seems to be slower than I would like.
   2. It accepts the N key for "next", but not M for "mark as unread", which is an issue.
   3. It always shows all the feeds in the left pane, even if they don't have unread content. It will make those with unread content bold, but when you have 150 feeds divided into multiple categories, this is really annoying because it requires scrolling up and down to find the feed you want.
      

[*]The Old Reader is supposed to be a direct replacement for Reader and it does respond to the M key (albeit slowly), but it also has some issues of its own:

1. While it can be configured to only show feeds with unread content, its UI is problematic - I don't really like something about the colors of its list view which makes it hard to read and it's quite slow - you will be seeing its "please wait" Pacman animation quite a lot when switching between feeds.
2. It seems to be *really* slow to update. I imported feeds into it and Netvibes at the same time and more than a day later it only has 38 items where NV has 144 and some of those are old ones. I'm not sure how many Reader saw because I cleared almost all of them. It just doesn't seem to want to update.
   

I guess I'm going to have to check some of the others as well. Reader, while not perfect, made RSS look easy. I'm disappointed to find that these services don't provide the desired experience.

In about a month Google is going to be shutting down Reader, which is their RSS reader service. Since I rely on RSS on a daily basis, I'm now going to have to find another RSS reader. There are various options online (like this one), but I was wondering if people here had recommendations for readers based on your own experience.

Here are my basic requirements:

1. It has to be web based. I move between different computers and I want to see the exact same thing on all of them, so not Outlook.
2. It has to be able to import my Reader subscriptions.
3. It has to allow the option of looking at each feed separately (If I understand correctly Outlook basically throws everything into your inbox and I don't want something like that).
4. I don't need something with a mobile app or anything like that. I usually only access these from PCs.
   

Cross post (with a report) - http://forums.ni.com/t5/LabVIEW/Error-Code-1604-happens-when-a-ring-or-enum-is-slected/m-p/2351176#M734172

A bad VI generally does refer to a broken VI, so I would expect that they would be broken.

One explanation would be that these VIs are meant to run on a real-time target and you mass compile them from a desktop target, where they try to use features unavailable on the desktop and therefore appear broken. Once you open them through a project, they're not broken because you opened them on the correct target.

I'm told that if you right click the project in the project tree and select the mass compile option, then things would compile on the correct target, but I don't have any experience with this myself.

But with this idea In Beta, perhaps there will be a built-in solution (I don't have the 2013 beta so I can only speculate on what might be coming).

We have platform and version specific features in the CCT by placing them in dynamically called VIs. In principle, it would be possible to support scroll-zooming on non-Windows platforms in LV 2013 or later by wrapping the code in such a call, but it would require several VIs to support the various platform and version combinations (probably Win <2013, Non-Win <2013 and >=2013).

the LLB <vilib>:Utility:inputDevices.llb isn't found, I think this llb is Windows only.

Yes, as far as I know that's true. As far as I can tell from my memory (and your image), that's the part of the code that handles the panning and zooming of the preview image. I believe originally this used only events, but I guess from the label that Ton added zooming with the mouse wheel, which wasn't supported with the event structure. I don't have the code in front of me, but I see no reason in principle why this code can't be moved to a dynamically called VI, thus making it compatible again.

I'm not sure when it will happen, because I don't currently have access to the CCT repo and I don't even remember which version it's currently in (7.0 or 2009). If you happen to want to make the change, I'm sure it will make it likely to go faster.

What exactly is the problem? I'm not well versed in the VIPM package build settings and I know nothing about the Mac, but as far as I know, the CCT should in principle work on the Mac. I know that we wrapped all the platform specific code so that it would. Is it just a matter of setting a flag in the package to mark OS X as a supported platform?

OK, you're right, the event does seem to be public and even has a help item. It was probably made public by accident, but since it is public, maybe now we can file it as a bug.

I didn't actually look at this (at least not recently. I do seem to have a vague recollection of trying it in the past), but my guess would be that this is a private event which was never fully implemented. Maybe someone wanted to do it but ran into problems or didn't have time. I'm assuming you have the superprivate keys in your INI file?

I found this way easier than vipm, to make sure all development system uses the right sets of VIs.

I suggest you try this, it's so easy, and has been working really good.

The main problem with this (other than that you need to edit reuse code directly in user.lib, or vi.lib, which is what NI recommends now) is that when you have a new version of LV you now have a repository which has VIs saved in version X used for version X+1, X+2, etc. If you save them (because LV will ask you to after recompling, unless they have separation enabled), then when you want to update, you will get conflicts. If you want to edit the reuse VIs, then you have to do in the oldest LV version, which is reasonable until you get to a point where you want functionality which isn't in the old version. Then you have to decide to skip the functionality, stop using the old version or force the old version to only update to version X of the code.

I like the concept but in practice you may find it difficult to update the UI while the main.vi is being loaded.  I've noticed that when I do a Open VI Reference the UI is locked and doesn't update (something about thread swapping).  So I don't know how you would update a progress bar with the new memory loaded percentage.  The reason the the Sub-System loading works, is because there isn't one Open VI Reference call, there is one for each sub-system and then one for the main, and between each of these calls there is a time where the UI can be updated.  If you can get an example working using this memory usage method I would be very interested in how it works.

What was actually described there was a second EXE which functions as the splash screen. That second EXE saves what the RAM usage of the real EXE was after loading and then simply monitors RAM usage as the real EXE is loading and displays that as a percentage of the saved value. I'm assuming that should give a reasonably accurate answer, assuming a clean load of the app uses more-or-less the same amount of RAM (which may not actually be the case if you close the app and reopen, etc.).

I would suggest using the system restore option on Windows to go back, but I'm pretty sure that the install process adds multiple restore steps, so that the older restore point would be gone.

You could try finding msiblast, which is a program used to remove NI software, but I wouldn't consider that safe. My primary suggestion would be to contact NI directly.

Jack Dunaway has a good article on the subject here - https://connect.wirebirdlabs.com/knowledgebase/articles/172999-segmenting-the-run-time-engine

He doesn't talk about identifying GUIDs, but I hope what he has there should cover it. At the very least, you could try looking up the version numbers.

The other option, of course, is to build the full installer using LV, which is certainly safer.

In source I have this structure.

 

C:ProjectsExample.lvproj

C:ProjectsActor 1Actor Core.vi

 

In the EXE it appears to be this

 

<dir>My Example Program.exe

<dir>My Example Program.exeActor 1Actor Core.vi

 

What about files not relative to the project like vi.lib files?  Where are they stored in the EXE and are they subject to change?

I never looked into this too deeply, but it seems to me like the structure is simple enough - the top level in the EXE is the project (or maybe if there are other files in other folders it's not the top level) and everything else is relative to that exactly like it was in source. vi.lib and other such files are saved under a folder called 1abvi3w, if memory serves. All this should be easy enough to test manually by getting a reference to a few VIs inside the app and displaying or logging their path property (or you could just write a VI which will parse the entire hierarchy and go through the data manually).

For a more generic solution to your current method, what you can do is statically analyze the entire hierarchy (assuming you have a simple hierarchy with only a few top level VIs) and then list it in reverse and load all the VIs in the EXE in that order (i.e. from bottom to top). I think there was a thread last year which talked about this and maybe even had some examples (I have a vague recollection of Norm participating there, so you can go through his stuff).

I'm somewhere between A and D, but I have only felt the need to create a few controls (hmm, maybe I should replace "need" with "justification", thus making me a C?). I will certainly add to the others in saying that they don't feel fully baked, both in terms of functionality and ease of use, but I would still consider them as a viable tool (although that might just lead me to mje's position in the end if I run into the correct Xctl.). I will also add that resizing XControls can be a pain, as well as having pop up controls in them, because contained controls can't appear outside the bounds of the XControl.

And speaking on that specific topic, there were some discussions on this before. Here's one example - http://forums.ni.com/t5/LabVIEW/An-experiment-in-creating-compositable-user-interfaces-for/m-p/1262378#M529154

This could return a false positive if you run it on a class which doesn't inherit from your base class and has a VI with the same name, but I'm assuming you won't do that.

Which brings up another thing that bites you every so often when updating td enums connected to Case structures.  Sometimes a list 'a','c' gets silently changed to a range 'a'..'c'

This is an appropriate place to link to the relevant idea, which has way too few votes - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Case-structure-prevent-automatic-change-from-selector-value-list/idi-p/1687284