jgcode

A workaround: it seems that any picture that has a width of at least 500 pixels is displayed well.

How many pixel incrementations did it take to figure that one out!

Good Job

OK so that did work and now I'm intrigued that having a path control with the absolute path to the VI didin't work but this process did. The question to NI is: what's the thinking on that one? Or to say it another way, shouldn't the absolute path work -- always -- regardless of anything else??

And thanks for the tip. I'm no longer blocked.

No probs.

What absolute path are you using?

I am sure you could still get to it, but you would have to be using the correct one.

The easiest way to do this is to use the reference and path property node to write it to the screen so you can see it.

Then you could try that path in accessing the VI (just to test it).

The 9.0 build model is a similar structure to whats on disk however, depending on your linking it can change.

Plus the .exe "folder" will be in there somewhere to.

Using a reference is by far the safest.

I haven't had to deal with resolving paths for a while now

The hypertext is the bug.

The image being appended is a feature of the forum software. Any attached image that is not used in the post is automagically shown.

Ton

Hi Ton

It is the forum software that is creating the hypertext.

The only difference between the two screenshots is that I moved a quote around.

The forum software removed my pictures, replaced them with the hypertext then appended them to the bottom.

So its not the case that "any attached imaged that is not used in the post is automatically shown", they were included originally.

Hope that makes more sense,

Cheers

-JG

Just make sure you only do one event per Event Registration Refnum when bundling the Event Registration Refnums into a cluster. I originally tried to group "sets" of events this way and revealed a bug. But, the way Ton has displayed will work since he just has 1 event (in this case, user event) per Event Registration Refnum.

I have seen remapping to other events, if you edit clusters.

Are you referring to what Jim has posted here?

Not particularly, but I don't usually code much when I see this:

UFC... that's lame when Montreal Canadiens are going for the Stanley Cup!

Seriously, we only hear about hockey these days...

Whats hockey?

We'll continue this offline... probably on a rainy day!

What does that mean?

Does it rain often in Montreal?

(Home of the great GSP - you didn't go to UFC 113 @ the Bell Centre did you?)

This is just an initial query to see how much need there is for a mid-level api and determine if it's worth my time to set up a public portal for the LapDog source code.

Ok this sounds really exciting...

This is because I am trying to release packages now that contain reusable class that I can use in my projects.

I am I seeing massive performance increments (not CPUs stuff - I mean in respect to my time in rolling out a project).

There is a lot of work setting things up, but the payback can be huge.

So I can see this as really beneficial to the community.

No point reinventing the wheel - lets get together.

As soon as I read this I thought OpenG too.

I think anything that can improve LabVIEW is a good thing, and who knows down the track they may get natively implemented like some OpenG functions have in the past.

I think OpenG would have the credibility and the backbone to roll this out, so definitely look there first (IMHO too)

Here is a list of things I am working on at the moment:

(I have decided to start with 2009 for this, there is just so much more I can do there then say 8.2, so I don't see the point)

Data Class (objects that have LV datatypes with get and set methods so I can send/store/manipulate data as objects)

Circular Buffer (stores generic LV Object, but I make wrappers for common Data Classes (E.g 1D DBL) so I don't have to convert in my code)

Counter

Error Logger

Timers

Window (Front Panel) Settings

File IO Manager (creates a file with a header so file versioning is easy, extend to implement e.g. a config file to manage sections and reading/writing)

File IO Interface

Various UI Effect

Making a plugin Run Time Menu, that is also linked to buttons (e.g. enable button enable RTM item, turn button On, check RTM item; select an enum value, check one item in a list in a RTM submenu etc..)

Now, none of these maybe of interest, but that is just some stuff I am up too.

I like LVClasses so I am down for pretty much anything.

PS - What is with the name?

Hi Mods,

I have noticed the following about quotes affecting the embedding of images in posts.

Not show stopping but I though worth mentioning if not known:

With no quote after my images I can display my images exactly where I want to in the post:

When I add a quote to the mix after the images, then I get a hypertext reference where I wanted my images and now my images are added at the bottom of the post.

Cheers

-JG

As for the API, it's missing some bits and pieces, and I'm putting together a better version as we speak. I've had some issues (minor) with building a temporary package, so I have nothing at the moment... I shall try to have it for NI Week. I did think about asking you for collaboration in integrating some methods for icon management, since you seem to have worked a great deal on this. I guess I'll PM you when I'm ready to explore that.... if you don't mind of course!

Collaboration sounds like a smashing idea!

I have been playing around with Layers using the Icon Editor API, so its all 2009.

But there may be some stuff there that would be of benefit.

We should definitely have a chat offline.

For any class that is in memory (and a never saved class is obviously in memory), just do "name of class" + ":" + "name of class but replace .lvclass with .ctl" and wire the resulting string to the Open VI Reference primitive. Voila.

Getting to the class by the Name property works, whereas the Path property returns a blank when the class is not saved and the Open VI Reference for the Control returns the error 1004

It all seems so Basic I Core 1 'ish now....

I learnt something and that is never a bad thing.

Hi Jon,

You can get it through the class' library children. The type is "Class Private Data" and it's the only child of this type in the library. The other method relies on the path being known, which doesn't exist yet if not saved, or at least, it exists only in a temporary location.

As a bonus, you can get it from LVClass API...

But here's how to do it without:

You knowledge of the force class is strong

Although I always want to know how to do it myself.... I think its time to get more intimate with your API (I have downloaded and looked at it before, just so you know).

Do you recommend this over the other method? I remember AQ mentioning about the class being in memory before getting a reference to the .ctl etc...

Kudos!

Howdy!

I use this method of getting the .ctl reference of a class (posted by some of my smashing friends here at LAVA ).

However, when the class is not saved I get error 1004.

So my question is... ...Is there any way I can get a valid reference when the Class is not yet saved?

Cheers

-JG

Yes that does make sense. I'll give it a try. Thanks!

Cool - did you get it to go?

Ok, I have been seeing this for a while.

In PMs and now posting.

Glad? to see others have same problem (hey - at least that means I am not alone!)

Mods

Is this an IPB Known Issue?

Is there a workaround?

Cheers

-JG

I'm a little confused. The first dynamic "object" I point to the file location for the VI I want to call dynamically in the subpanel?

Just drag and drop the VI you want to call dynamically into the Static VI Reference and it will show the icon for that VI.

Now you have a reference to that VI.

Now use a Property Node to get the VI's Path so that whether you call this in Dev or RT it will be the correct path.

Hope that make sense??

Cheers

-JG

Right, no shooting allowed...

I do what I've always done. It is a path control with the full path name of the VI that is to be included in the tab of the subpanel.

So don't shoot me if something else should be done to support the 9.x file format.

val

Deal!

Give this a shot and let me know how you go.

OK, this is a real mystery to me. Probably I just don't understand the implications of the setting but here's the scenario. I have a project with a top-level VI that has a subpanel that call two different VIs, each in a separate page of the control. So, shift to page 2 and one of the VIs is visible, switch to Page 3 the other is and the other tabs access controls that are internal to the top-level VI. The called VIs are included in the Always Included list in the Source Files page of the App Builder. Inclusion Type is set to Include if Referenced with the Application EXE as the destination. When i use the 8.X file layout in the Advanced page, the build succeeds and the app works correctly, loading and running appropriate VIs as each page is selected; however, if I deselect using the 8.x file layout, the pages are blank when called unless the flat VIs are included on the hard drive of the target system, in the correct location per the development file layout. Obviously I'm not setting up the inclusion process correctly but I really don't get what to do to make it work correctly when not using the 8.x file layout.

Any help would be appreciated including pointing me to relevant KBs that I've overlooked in trying to resolve this.

Hi Val

I risk stating the obvious... (so don't shoot me down )

The VI paths change between build models (8.x vs 9.0).

It sounds like your inclusions are fine

How do you resolve the VI paths so that you get a reference to them?

I tend to use a Static Reference now-days rather than trying to resolve the valve of the path data type (based on Dev vs RT) so it doesn't matter what the internal structure of the 9.0 build is.

-JG

PS - I like to create a VI Tree.vi and stick all dynamic VIs in there so I only have to Always Include one file - so I don't forget to add new ones to the build spec.

No need to shout

I have posted an Idea to make it possible to Implement Quick Drop from the LabVIEW Project.

This is more for interfacing to custom plugins, rather than native options.

I currently use work arounds for this which is fine, I just think it would be faster this way.

And may open up other possibilities...

Here is some side chatter in the QD Group

"I wire up the wizzle on the wizzles and hit the front bizzle, contrizzles and displizzles on my LabVIEW front pizzle"

This is freaking hilarious I can't stop laughing, these guys are great.

I love Gansta Rap and LabVIEW - whoever combined the two is genius!!!!

Here is another one I found after you posted that one:

Why all these VI's are Reentrent ? Is there a fundamental reason for this or just your choice. I am just trying to increase my understanding.

I can understand that "Get All.VI" needs to be as you do a recursive call on it, but I do not really understand why all the other are. In fact I wonder if you really want things like Item Add.vi to be reentrent.

Along the same lines I assume that Debugging is disabled because the VI's are Reentrent ?

Finally in the "Get All.vi" which is Reenternet I noticed it calls the "Merge Errors.vi" which is itself not Reentrent, should this really be replaced ?

Hi Dannyt

I can't speak for Norm's choices but you can use reentrency to create non-blocking VIs which means if that subVI is used in lots of places, they won't effect each other. This is the choice I made when designing my reuse library, I was under the impression this was common.

As it turns out recently others have voiced against this - saying even NI subVIs aren't reentrent e.g. Merge Errors would be a bottle neck (as a side note Darren has pointed out the poor performance of this VI in a nugget and there is an update for 2010 as shown in the Idea Exchange Forum.)

Anyways here is some more discussion on the subject.

Here AQ talks about the algorithm used for shared clones.

Enjoy!

Cheers

-JG

I've got to communicate dynamically with several stations which carry out essentially the same operations, where the parameters are individually input by UI and operation by semaphore-controlled tool function.

Right now I've got the project set up as a QSM as seen in the attached photo.

The top level VI initializes itself, the subVIs and then is idle while the subVIs operate unless an error or stop command is passed. I find myself saving each subVI as a unique file in order to maintain operation of the state machine for each, rather than what seems logical - to place a single reentrant VI. This brings to light my question - is there a better option than a QSM?

You can make a FGV a reentrant VI, but because it contains persistent data (USRs) you use the preallocated option for reentrancy. Therefore, every instance placed on the block diagram will have a unique state.

That may help.

I moved it to the Quick Drop Plugins category as requested.

Mark

Kudos!

example BOM file

-------------- ClearCase Build Info (Build Start) -----------------

ClearCase Build View : petes-dev-ats-814

ClearCase Config Spec :

element * CHECKEDOUT

element * /main/dev-ats-814/LATEST

element * /main/B591-ATS-2009NOV24 -mkbranch dev-ats-814

element * /main/0 -mkbranch dev-ats-814

create_message_event.vi,P:\testTeam\ATS\Projects\test_exec_framework\user_events\create_message_event.vi,\main\1,

create_exit_event.vi,P:\testTeam\ATS\Projects\test_exec_framework\user_events\create_exit_event.vi,\main\1,

run_sequence_data_type.vi,P:\testTeam\ATS\Projects\test_exec_framework\general_type_defs\run_sequence_data_type.vi,\main\1,

update_symbols_run.vi,P:\testTeam\ATS\Projects\Sandpit\update_symbols_run.vi,\main\1,

Open File+.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\Utility\file.llb\Open File+.vi,CC PATH NOT FOUND,file.llb

kHz-MHz.vi,P:\testTeam\ATS\Projects\Sandpit\kHz-MHz.vi,\main\1,

NI_MAPro.lvlib:ma_Check for Equality with Precision.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\measure\mamon.llb\ma_Check for Equality with Precision.vi,CC PATH NOT FOUND,mamon.llb

NI_MAPro.lvlib:ma_Range Check with Precision.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\measure\mamon.llb\ma_Range Check with Precision.vi,CC PATH NOT FOUND,mamon.llb

NI_MAPro.lvlib:ma_Limit Test Outside.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\measure\mamon.llb\ma_Limit Test Outside.vi,CC PATH NOT FOUND,mamon.llb

NI_MAPro.lvlib:ma_Limit Test Inside.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\measure\mamon.llb\ma_Limit Test Inside.vi,CC PATH NOT FOUND,mamon.llb

As you see starts with the ClearCase Config Spec used for the build then lists all the files used in build.

Each line is comma separated look like

VI name, full filepath, ClearCase extended path info (if a ClearCase object), llb name if VI is in a llb.

Thanks Kudos

Certified 5-4-2010

Placed in LabVIEW OOP Catagroy

Thanks for your time Mark.

Would it be a better suited located in the new Quick Drop Plugins category (under LabVIEW IDE)??

What are your thoughts?

Cheers

-JG

BD Cleanup gave it its best shot ...

Wow! That actually looks half decent!