Jump to content

Strange crosses in the palette


Recommended Posts

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

post-7450-098645500 1286263767_thumb.png

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

Link to comment

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

post-7450-098645500 1286263767_thumb.png

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. :book:

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

Link to comment

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).

Link to comment

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.

post-17453-071167000 1286278687_thumb.jp

post-17453-076652500 1286278713_thumb.jp

Link to comment

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...

Link to comment

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. :D

So, problem solved ... somehow ... :beer_mug:

Link to comment

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...

Link to comment
  • 4 weeks later...
  • 5 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

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