LabVIEW 8 bug?: reusing custom controls with imported graphics

[travispape]

By the way, I've noticed that the installer for the State Diagram toolkit doesn't work with LabVIEW 8.  It inisists on installing itself into the LabVIEW71 folder in "c:\Program Files" even if the folder isn't there.

Simply dragging the files into the appropriate places in LabVIEW8 folders doesn't seem to be enough to get LabVIEW8 to give it a place in the new VI dialog.

But the main thing is I'm still looking for a way to have my LabVIEW 8  and be able to use controls with imported pictures.

[ckis]

Hello everybody,

could somebody find a solution to this in  the meantime? I just experienced a similar problem: I'm using custom controls with imported pictures as well and it worked fine up to now even with LV 8.0.1. But after working on some subvi's some of the graphics were replaced by the "stretched d". My changes didn't have to do anything with the broken controls. In some controls all graphics are messed up in other controls just a few or none. I'm using LV 8.0.1 on a linux machine (Suse 10.0). I'm not using any build scripts, just running LV source code.

Reloading LV, mass compile or reboot didn't help. I can manually replace the controls with the original type def buts thats a lot of work and I wonder when I would have to do that again.

I'd appreciate any hints. Thanks.

[jpeters]

I believe that a fix for this problem made it into 8.0.1.  However, if you saved your VIs with any images already replaced with the 'd' we cannot fix them.  If you have copies of your VI before this corruption, you should rebuild using those.  If you don't I suggest rebuilding the typedefs as necessary.

Jeff Peters

LabVIEW R & D.

[ckis]

Thanks for the reply. So I think I need to fix my vi manually. But is there another patch for LV 8.0.1? I'm using LV 8.0.1 quite a while now and worked and saved this vi or its subvi's several times without any problems. I just want to be sure not to have to fix that every few weeks.

Clemens

[jpeters]

---

@ckis wrote:
Thanks for the reply. So I think I need to fix my vi manually. But is there another patch for LV 8.0.1? I'm using LV 8.0.1 quite a while now and worked and saved this vi or its subvi's several times without any problems. I just want to be sure not to have to fix that every few weeks.

Clemens

---

I just double checked and it looks like the fix didn't make it in the patch 8.0.1.  Sorry for the confusion on my part.  The only workaround that I know of is when you are editing VIs with custom graphics you should not have very many drivers or items in user.lib.  I don't know exactly how many "very many" is, but this problem is related to the number of images currently loaded in LabVIEW when you save/load your VI.

If your VI has been saved with the "d" image, you will have to rebuild the images manually.  Unfortunately, without the fix I cannot guarantee that it won't happen again.

Sorry again for the bit of misinformation --..

Jeff P

LabVIEW R & D

[travispape]

---

@jpeters wrote:

I just double checked and it looks like the fix didn't make it in the patch 8.0.1.  Sorry for the confusion on my part.  The only workaround that I know of is when you are editing VIs with custom graphics you should not have very many drivers or items in user.lib.    <snip>

---

In my case, it was instr.lib.  I removed a couple of large instrument drivers from instr.lib to work around the "stretched d" build problem.

[jpeters]

---

@mochalatte wrote:

---

@jpeters wrote:

I just double checked and it looks like the fix didn't make it in the patch 8.0.1.  Sorry for the confusion on my part.  The only workaround that I know of is when you are editing VIs with custom graphics you should not have very many drivers or items in user.lib.    <snip>

---

In my case, it was instr.lib.  I removed a couple of large instrument drivers from instr.lib to work around the "stretched d" build problem.

---

mochalatte :- nice to hear from you again.... and yes, I wasn't clear about what I said.  I should have said:

The only workaround that I know of is when you are editing a VI with custom graphics you should not have very many drivers installed (usually in instr.lib) or items in user.lib.

Basically, you just don't want LabVIEW to load a lot of images into the palettes -- there are other ways that this can happen I suppose, like creating custom palettes with pointers to directories other then user.lib/instr.lib but these are the usual culprits.  So if you run into this problem -- reload from a backup, rename intsr.lib or user.lib to something that LV cannot find, then relaunch LV and edit your VI.

In most cases, this should probably work.  It isn't pretty, but at least your VI will not become "corrupted".

Also, it is probably a good idea to use strict typedefs whenever possible instead of vanilla custom controls.  This way, if a corruption does occur somehow, you can just rebuild the typedef and then all instances will be automatically fixed when they update from the typedef.

Message Edited by jpeters on 06-07-2006 08:41 AM

[ckis]

Ok, next time it happens i'll give that a try. It just looks a little bit unpredictable to me because I didn't do any changes to instr.lib or user.lib recently. But maybe thats a general problem of lv 8xx, it also sometimes chrashes while saving after changing typedefs etc.

Thanks for the tip,
Clemens

[gabrielinpompin]

Tenia un problema parecido, pero en lugar de aparecer una "d" me aparecían figuras diferentes como circulos, rectangulos, y estos cambiaban al enviarlos al fondo o al frente, el unico control que no tenia la "d", era el de hasta el frente. 

Incluso las otras imágenes se alteraban.

Después de modificar muchas cosas, la solución que encontré fue colocar en el block diagram todo dentro de un case, dentro de "TRUE" y en "FALSE" un ONE BUTTON DIALOG.