jgcode

I've had the same problem. I'm not in the office right now so I can't reproduce but I recall it having something to do with polymorphic VIs with LVOOP or something similar.

Either way there's a particular constellation which causes the new Editor to bomb out and revert to the old one. If I find out exactly what causes I'll post an update.

Shane.

Cool - you may be onto something!

On a side note there is also this LVOOP Constant Bug which I have witnessed.

Unfortunately it has gone unanswered on NI's forums

http://forums.ni.com/ni/board/message?board.id=170&message.id=439612&requireLogin=False

Ok, further checking, you actually have to break the new icon editor to make it not open in the other application instance (I think I was getting confused with using custom editors in LV 8.6....)

1) Start LV 2009

2) Open <labview>\resource\plugins\lv_icons.vi

3) Make some trivial change that breaks the vi (e.g. create a broken wire segment)

4) Attempt to edit an icon

Even easier, just rename Open <labview>\resource\plugins\lv_icons.vi to something else and then only the old icon editor will show.

PJM

Thanks for the info however, I was just editing an icon in the LV09 Icon Editor and it made the switch to the LV8.x one. I was not playing around with the source code.

I have been trying to bring it up from the LV09 Icon Editor again, but unsuccessfully

Yes, I've done that. Attempting to edit the icon of the new LV2009 icon editor will open the 'traditional' editor. I would imagine that any action that breaks the new icon editor or stops LabVIEW from launching will have this effect.

Are you able to please list the steps required to show the traditional editor.

Cheers

In response to a LabVIEW feature request I was exploring an LVProject file for the build path.

And I noticed LabVIEW supports some symbolic elements:

The element NI_AB_PROJECTNAME is the actual project title. I wonder if there are more of these options available.

Ton

PS this was seen in LabVIEW 2009

Great topic.

I was recently trolling through a 9.x project looking at these so that I could resolve the build spec paths into absolute paths.

This was due to the new build feature in 9.x and how the paths are constructed and the issues associated with that.

I wanted to add in 9.x support for my build script which would transparently build the Executable or Installer under e.g. C:/dist and then move all files back to the original location in the build spec to avoid any build errors.

Due to the unknown constants in the build spec, I was not able to implement it as above.

But I came up with a workaround that does the job.

Would sure like to know what you find you tho.

Cheers

JG

I made the 8.x LabVIEW Icon Editor appear in LabVIEW 2009!

It was by accident

Has anyone done this?

I can't seem to replicate it.

Nonetheless it is interesting that it is still there.

Cheers

Tales from the other Dark Side

Read through the company's reply...

Seriously, that makes my day.

Great legal comeback by the store:

"If Jedi walk around our stores with their hoods on, they'll miss lots of special offers."

This was in version 8.6..

I just checked 2009 and have to confirm they now look the same.. Looks like this little gem of a hack is broken in LV2009.

Well its not completely broken - its much better then the native version.

I am happy to gave gotten the downloads form this topic, even if it is one.

For all who don't see the difference, here's an example comparisson:

It's very subtle, but it's there.

I can see the difference in your post

What version did you post in as I am getting this in LV09?

(I even downloaded everything again just to make sure)

No need to correct your grammar (but probably mine )

I just meant that there might be a difference in LV8.5 and 8.6, that prevents the 0 pixel version from working in LV8.6 and higher.

/J

Ok, I misread your post

Can it be that the hack is no longer working in LV 8.6 and higher?

(I think the original was made in LV8.5)

/J

Sorry, to correct my grammer...

I can see the difference between the native LabVIEW cluster and the three posted .ctls when I create arrays of these clusters.

I cannot see any difference between each of the three posted .ctls when I create arrays of these clusters.

Thank you.

This fixed it.

I'm happy again

//Mikael

Good to hear

Hi

My version of LabVIEW is behaving odd when it comes to Data Entry limits.

Have YOU seen the same problem?

When I open the “Data Entry…” option for a numeric the first time it does show me the right limits for that control.

When I open the same option for the next numeric control these values don’t show the correct values.

They still show the first opened control’s Data Entry-limits.

And if I change the values, that values changes for the other control not the one I open the dialog from.

This is in LabVIEW 8.6

Cheers,

Mikael

This patch (for 8.6.1) may help???

The Data Entry Properties Dialog Box for Numeric Controls Do Not Work Correctly in LabVIEW 8.6.1

http://digital.ni.com/public.nsf/allkb/765EBEBE6568CB098625756700718B66

Cheers

JG

[edit]

Yep, I was right, it seems fix is to install 8.6.1 and patch.

Hope you have a copy of 8.6.1??

http://zone.ni.com/devzone/cda/tut/p/id/7324

147779

Return "Data Entry" tab of Numeric Controls does not update properly

"Data Entry" tab of properties dialog only applies to the first numeric control for which the dialog is opened per launch of LabVIEW. This issue exists in LabVIEW 8.6.1.

Workaround: The LabVIEW 8.6.1f1 Patch has been released for this issue. KB 4UNGLN0R also has detailed workarounds.

Reported Version: 8.6.1 Resolved Version: 8.6.1 Added: 02/26/2009

[/edit]

The difference will be clearly visible when you put something into a cluster, set "Size to fit" and then make an array of clusters. It is a difference between 1 px and 2 px element gap.

Of course this is what I did when I said I could not see any difference.

It all looks the same to me

My eye maybe out tho??

I think these two are the ones that AQ posted originally.. (I safely tucked them away in my svn repo. )

I think these are saved in 8.6.

What is the functional difference between the three controls now posted?

They all look like they give the same effect to my eye.

???

Should be fine. (havn't tried what your doing but have done similar things).

There is a flashing LED x-control around somewhere here that spawns a vi dynamically as a timer which is similar to what you are tring to achieve.

Sweet, I remember seeing that one posted, I will check it out.

I think that is the way I am going to go.

Howdy!

Is it possible to have an X control that can spawn a dynamic User Interface VI - such that the UI is non-blocking in the X control thread? I have done X Control with static UI - easy. I just want to know if it's there is any problems that may arise or it anyone else does that before I go down that path.

Right know I have my control in a main VI and I have a separate UI that runs in parallel to the main VI and that "acts" only on the control.

The parallel UI is run by by main VI and comms/data go through the main VI to the control.

I would like to encapsulate the control and parallel UI together.

However, the UI and control must run at the same time - the parallel UI cannot block the control.

Would this work ok?

Cheers

JG

You've got to be logged in to download it.

Borderless Cluster.ctl

Am logged in!! But still not working.

I think there was a problem with my account activation??

Thanks heaps

Thanks! It's really cool.

Of course LAVA lost the attachment, but I found it posted at OpenG forums: http://forums.openg.org/index.php?showtopic=594&mode=linearplus

And here is how the control looks like now:

Can someone please post the hack, the old LAVA links seem dead and I am having trouble (?) getting it from openG.

Cheers

Very Cool

although I cannot predict which order each operation is executed the order will be the same each time the program is executed?

I am pretty sure you can't - as this is where the dreaded race conditions come into play.

I have seen this a bit from older code, that programmed with this not in mind (e.g. lots of globals)...

It worked fine on their PC at the time. Move on to different PCs - multi threading, hyper threading, Core 2 Duo - where the timing characteristics of the code are now different and whammo - race conditions start popping up.

Same code, different PC.

Hi All,

While writing a RCF plugin I bumped into this problem which I was also able to reproduce outside of the RCF framework, so it's probably not a framework issue.

The piece of code shown tests a diagram's selection list for class wires and returns the wire ref and class path of the first class-wire found. This code works whenever the VI that it's operating on is in the main application context. When I have opened the same VI from within it's project, the variant to data function returns error code 91 (The data type of the variant is not compatible with the data type wired to the type input). However the datatype in the variant is under both circumstances exactly the same.

Also, after the error 91, LV becomes instable. Doing edits in my script-VI or even just saving it gives me an fpsane crash on line 432.

Your thoughts please? Am I looking at a bug here?

Jeffrey

Hi Jeffery

I don't know if its a bug?

But I ran into the exact same problem using the property node Data Value of a Class with either Get LV Class Path.vi or Get LV Class Default Value.vi and RCF - it ran fine in LV but not the application context of RCF.

All I wanted to do was find the Class Control's Class Name

So I typecasted the selected GOObject/Control reference to a Class, got the data value, wired that to the Get LV Class Path.vi, to parse the class name or something like that (I can't remember exactly).

But there was a much easier way: All I had to do was get the Library Reference from the VI property node (RCF was acting on a Class Data Member VI). Then get the class name!!

Depending on what you are trying to do there may be an another way i.e. if you just require a Library Ref to the class.

What are you trying to do?

When VIPM installs/uninstalls a package it saves the package configuration file in the temp directory. It should be possible to read the configuration file from the temp directory and extract whatever information you need. Let me know what you find out.

Ok, I played around with this for a while now and here is the low down:

• After searching around I have been unable to find the .spec file for the currently installed packaged in a temp directory. (Which temp directory is it? C:\Users\<me>\AppData\Local\Temp???)
  
• The other location I may have been able to use is the cache. But I thought about this I can't be 100% sure where the cache folder is: Is it C:\Program Files\JKI\VI Package Manager\cache or C:\Users\<me>\AppData\Local\VirtualStore\Program Files\JKI\VI Package Manager\cache?? (PC dependent)
  
• Therefore I decided to store all files I need to manipulate in the package to a known location. I choose C:\Users\<me>\AppData\Local\Temp\OGPB\...
  
• Now I know exactly where they are. The path is set in the spec, and I just have to create it in my scripts. Easy.
  
• I handle all the installation and uninstallation of files with scripts. Heck, I even wrote a small API that I can reuse for this stuff that creates a file with all the installed file paths so I can clean them up nicely at uninstall.
  
• I little bit more work for this edge case, but now I have my package for icons and I am very happy fo' shizzle
  

I've looked for installation path information to use in my post-install/pre-uninstall scripts too, with pretty much the same result. I did find one avenue that showed some potential, but time constraints have prevented me from investigating it deeply.

Yep, it sure would be handy if the same info was available that is in the VIPM build hooks.

I can't edit my original post but there is now a

[cross post to JKI]

Ah. Thought you wanted to definitively know. Just for reference. It will also show as maximized.

I am using LV2009 and FP:State property toggles between Standard (in subpanel) and Closed (not in subpanel)- but not maximized ??

That is ok tho, cause now I have a way for the VI to test itself.

Cheers