Strange crosses in the palette

[vugie]

Can anyone tell me why do I see such crosses in my palette?

They are in only one subpalette, palette work normally (well, almost normally - once VI's from this palette changed to ? on the DB).

There are no such crosses during palette editing (BTW palette editor start takes about 2 minutes). I already tried rewritting mnu file with palette API.

LV 2009

[LogMAN]

Can anyone tell me why do I see such crosses in my palette?

They are in only one subpalette, palette work normally (well, almost normally - once VI's from this palette changed to ? on the DB).

There are no such crosses during palette editing (BTW palette editor start takes about 2 minutes). I already tried rewritting mnu file with palette API.

LV 2009

Hi, vugie

The VIs are marked as "private".

So, if you use libraries or classes and a VI is marked private, it'll be shown this way.

The problem is: You can't use these VIs until your VI is part of the class or library.

To solve the problem, open the library or class and mark them as "public".

Note:

VIs with red crosses are private.

VIs with yellow crosses are protected.

VIs without crosses are public.

Greetings, LogMAN

[vugie]

They are public and their class is public as well. I'm able to drag them from palette and use normally.

In the subpalette of this palette there are some VIs from the same class and they appear without such glyphs.

This palette looks the same after restarting LabVIEW and when installed on second computer.

As an experiment I tried to change scope of some other VIs from another class and another palette to private, then I refreshed palettes and there was no change in VI appearance on the palette (no glyphs).

[vugie]

vugie,

that palette looks might intesting!

care to share the contents ;-)

That's another story... I'll do it soon. Here is some preview

[ShaunR]

That's another story... I'll do it soon. Here is some preview

Can't wait for the Labview version of Halo

[LogMAN]

They are public and their class is public as well. I'm able to drag them from palette and use normally.

In the subpalette of this palette there are some VIs from the same class and they appear without such glyphs.

This palette looks the same after restarting LabVIEW and when installed on second computer.

As an experiment I tried to change scope of some other VIs from another class and another palette to private, then I refreshed palettes and there was no change in VI appearance on the palette (no glyphs).

That's interesting...

I've attached two files to prove. (TrayIcon.RegisterEvents and TrayIcon.EventHandler are of private scope)

Changing the classes content to private will cause the files within the palette to show a red cross.

I also need to update my last post:

Protected items are shown with a red cross too.

Sorry, but if your class is public and you have full access to all contents,

it might be a bug.

[vugie]

Sorry, but if your class is public and you have full access to all contents,

it might be a bug.

Actually jgcode pointed me to already filled CAR #185059 on similar issue. It concerns VIs which are member of a class whiech belongs to lvlib. LogMAN, you did your test for lvproj, probably if you would try it for lvlib, you'll get similar issue...

[LogMAN]

Actually jgcode pointed me to already filled CAR #185059 on similar issue. It concerns VIs which are member of a class whiech belongs to lvlib. LogMAN, you did your test for lvproj, probably if you would try it for lvlib, you'll get similar issue...

No wonder I never encounter an error like that.

I've never used classes in project libraries.

So, problem solved ... somehow ...

[vugie]

That is very cool indeed, on several levels...

From the screencast (or rather the bit of code I can see) it looks like you are using the 3d picture control. Is this easy to pick up? I have been tinkering around lately with a 100% G based 3d renderer (not getting very far unfortunately).

Yes, it is pretty straightforward if you are familiar with OpenGL concepts, however it is poorly documented - particularly for recently added features. There are some limitations which are hard or impossible to overcome - they concern mainly interactivity. There are also some performance issues - it mainly concern when control is embedded in VI (as opposed to separate window for 3D only).

I use 3D Picture very intensively in my projects an it serves very well as a scientific visualization tool without bells and whistles.

Writing your own realtime renderer doesn't make sense (other than fun). It hardly does even in C. I wrote something like an offline raytracer/renderer (but for terahertz radiation), but the performance was very poor and I moved the core part of the engine to C.

What make sense is writing a wrapper to one of existing 3D engines (there are hundreds of them - Crystal Space, G3D, VTK, IrrLicht, Ogre - to name a few of most popular). It is hard work, half by half in C I suppose. I tried to strat it, but I gave up. I remember that somebody here on LAVA said that he made some wrappers for VTK...

[asbo]

That's another story... I'll do it soon. Here is some preview

Very cool! Is the capture choppy or is the rendering choppy? The jumping around of the block diagram at the end inclines me toward the former.

[vugie]

Very cool! Is the capture choppy or is the rendering choppy? The jumping around of the block diagram at the end inclines me toward the former.

Of course the capture! How could you suspect something like this

[asbo]

Of course the capture! How could you suspect something like this

Not everyone is privileged with powerful hardware! I meant no affront to your code

[vugie]

Ha! red crosses in this palette suddenly disappeared

[vugie]

And appeared again

[MikaelH]

Has anybody found a solution for this yet, I also have it 2010SP1.

I.e. Class VIs display the Red-X

Cheers,

Mikael

[jgcode]

I filed the original CAR and thus Mike contacted me. It should be fixed in 2011.