PJM_labview

I think you should be able to create your own.

Here is how I would do it:

- backup the original Getting start code

- Close LV

- Rename GetRecentlyUsedFiles.vi to something like GetRecentlyUsedFilesOriginal.vi

- Open LV and OUTSIDE the project environement (don't open the lvliv) create you own GetRecentlyUsedFiles.vi (see connector pane image below) that call the GetRecentlyUsedFilesOriginal.vi. Save it where the other one was located.

- Close this VI

- Open the getting start window lvlib and relink the new one GetRecentlyUsedFiles.vi to the lvlib after LV complain that it is not part of it.

That should be it.

There might be some variation to this that might work better, but this is a starting point.

PJM

Edit: So much for this, AQ solution is of course a lot easier.

QUOTE (Michael_Aivaliotis @ Jun 4 2008, 01:23 PM)

I blogged recently about some great NI content. I watched some of those webinars. I also received a phone call a few days later from an NI sales person asking if I needed any help since I watched the webinar. Is it just me or is this practice down right annoying as hell. It really makes me NOT want to click on any NI content. This is not the first time this has happened. Anyone else annoyed at this?

PS. I wouldn't mind an email as much, but a phone call is over my limit.

After reading your blog entry, this is actually why I did not click on any of the webinar links. I did watch a couple of webinar recently and sure enough I got the phone call. As Chris mentioned they don't seem to have much information (other than phone number, name and watched webinar) of the person they are calling.

I came to the conclusion that I will need a dummy user name and phone number for these time were I want to watch a webinar.

PJM

Count yourself lucky, if you had to go back in LV 4 you will not have any undo functionality...

Fortunately I never had to experience this (I started on LV 5.0), but in my previous job I was using a cad drawing like software that had no undo. There is nothing more frustrating to make a change to a part, wait several minutes for it to render, and then realize than this change was wrong and you can't undo... --> You end up saving a LOT of copy of the same files, and when your files are large...

PJM

QUOTE (Aristos Queue @ May 19 2008, 09:51 AM)

This is correct behavior, not a bug.

Read here:

http://forums.lavag.org/Rings-and-Enums-ca...l&pid=33648

I understand, now that I have seen this thread, that this is the intended behavior. Still, in my opinion, the behavior is unexpected.

The help window (see screen shot below) specify: "Mouse Leave: Generated when the cursor leaves the bounds of the front panel".

http://lavag.org/old_files/monthly_05_2008/post-121-1211234807.png' target="_blank">

This is pretty straighteforward text. So to have a mouse leave event fire when at no point in time the cursor left the panel bounds is incorrect. I understand that implementation wize this context menu is in another window, but as a LV programmer I have no concept (and no control) about this. The only thing I know is that LV fire a mouse leave event while my mouse pointer remains in the panel.

intvsteve says in the other thread "One could, for example, fashion a custom 'popup' VI to be invoked on clicking a control that, to the user, looks and behaves exactly the same as a popup menu. From the perspective of the OS events, these are also indistinguishable. Obviously, in the case of the popup VI, you would, as the implementor, expect the mouse leave to happen, since the mouse entered another VI window (the popup VI)."

I agree with this, but the critical information in this example is that I am the implementer of this extra popup window and I expect this since I know I am creating this popup in another window. In the current situation where I am using the LV native popup menu, this is totally unexpected.

Since, apparently, this behavior is there to stay, the help should be updated to reflect theses exceptions.

PJM

QUOTE (Yen @ May 17 2008, 12:40 PM)

Is this like http://forums.lavag.org/Rings-and-Enums-causes-VI-Mouse-Leave-event-t8748.html&pid=33648' target="_blank">this?

This would appear to be the case.

PJM

Run the attached VI and see how creating the right click menu (in the "Pane": Shortcut Menu Activation frame) fires a "Pane": Mouse Leave Event.

This is an incorrect behavior.

Expected (Correct) behavior: no mouse leave event fire.

Similarly, selecting the right click menu and moving the mouse one pixel does generate a "Pane": mouse enter event.

This is an incorrect behavior.

Expected (Correct) behavior: no mouse enter event fire.

LV 8.5

Note:

• This bug is present as far back as LV 8.21 (I did not check any further).
  
• This has been reported to NI
  

Ya, I played with the "Get Conpane Image" too.

I actually gave up trying to programatically control of the Context Help Window (or create my own one) for the time being.

About the decompose and recompose icons, I think you are right. This definitively look like a skull.

PJM

http://flickr.com/photos/paintitblack/2439080330/

For more info do a google search with " What laptop does Steve Ballmer use for his presentations?".

PJM

anyone?

Given NI recent involvement with FIRST (among other things), I think we can expect it to raise a lot further in the future.

PJM

The

PJM

QUOTE (tcplomp @ Apr 10 2008, 11:48 AM)

Where can I find this 70....... VI?

Well, this VI came from inside an old example finder executable. It has no BD no FP and no icon, so it is of very little value if you plan to use it. I was just trying to figureout, at the time, how NI did the multi clumn glyph and I though this could have helped to have this VI Interface.

About why your example code fail, well it look like you are targeting only one column (the [-2;1]), if I recall you have set the active column first then set the glyphs (repeat for each column).

PS: Now, go give your $10 to LAVA

PJM

Write binary data if you can and this will be very fast. I did a quick test and I wrote about 500 MB in 30 seconds (<=> ~ 16MB/s).

PJM

I do not know how to use this PC card, but in the past I was able to send SMS from LabVIEW using the built in SMTP VIs and an Email to SMS Gateways.

Basically for each carrier you have to find an email address to target: This is typically like cell_phone_numer@carrier.com. Once you got that you just send an email and the email is automatically converted to a SMS send to the person cell_phone_numer.

The screenshot below show the settings for verizon (along with the SMTP VIs palette).

PJM

I am sorry to be the bearer of bad news, but the VI that you just posted do not have a block diagram. There is absolutly nothing that can be done. You have to either recreate it or use a backup copy (hopefully you are using a source code control)...

PJM

One of the thing to add to Justin comment (beside using VIPM which is a great idea :thumbup: [and this is what we do of course]) is that in my opinion, as a general rule, you should not "archive" in a LV version different than the one the VIs were created. If (or when) a user has to go back to work on this project, the LV upgrade you just made has introduced unknowns (and potential new LabVIEW bug) in the project. If the released software product has been made with LabVIEW x.x then "archive" the code in LabVIEW x.x version.

PJM

Thanks Ton, I am aware of this method, and there is another one that works for primitive (see image below). But I am trying to have the existing context help window to programmatically display a VI Description (like you have when you natively mouse over a SubVI/Primitive). I am not trying to rewrite the help window feature (although I may have to).

Note1: The attached VI shown in the screenshot will crash LV for indices value around 330, so save your stuff if you want to play with this.

Note2: Here is one of the "primitive" image I got using this VI: Coerce to Type...

PJM

QUOTE (crelf @ Mar 26 2008, 07:38 AM)

This is a kludge (I know it's not what you want, but it's something that actually worked pretty well for an old project of mine): Open a reference to the VI that you want to get the data from, then read it's "VI Description" (it's a the text from the VI documentation), then feed that into the "Description" of the FP node that the mouse if over - the context help window will update with the new description of the FP node. (I *think* I had to do this on a "Mouse Move" event to make sure the context help window updated, but I don't remember...)

Hey - I warned you that it was a kludge

Chris,

I already contemplated this solution and I am keeping it as a backup solution because by doing this you can't have the VI icon image and terminal name like you have natively when mousing over an SubVI/Primitive.

Thanks though.

PJM

Does anyone knows if there is any way (involving scripting or not) to programatically get the context window to display a specific VI documentation?

For instance I am looking for something that would take a VI path and will get the help windows to display this VI documentation.

Thanks

PJM

There are a lot of issues here. When in the middle on a drag and drop transaction (start dragging but did not drop yet) a lot of events are no longer fired (or they do fire, but occasionally).

The attached VI demonstrate this.

In this above example, the pane: mouse enter does no longer fire during the transaction but it does fire after the transaction complete; also the pane: mouse leave does fire only once.

By just pocking around a bit more, I realized that a lot of events are affected by this issue.

Note: LV Version >= 8.21 are affected (I have not tested on anything less than 8.21)

PJM

Download File:post-121-1206314759.viLV >= 8.21

QUOTE (Aristos Queue @ Mar 20 2008, 11:48 AM)

And *why* are you able to get speed and performance from the clones that you can't get from templates? Because they share just about everything with the original master VI. There isn't a separate copy made -- they share the data directly for pretty much everything except the operate data of controls/indicators and the flags for which wires have breakpoints...

While this is probably part of the performance issue, I am suspecting that the fact that it is not possible to instantiate a vit instance while the template is in memory is probably also reponsible for the performance issues I am seeing. For every vit instantiation, LV has to read the VI from disk. For reentrant VI it is possible to use a static VI reference, thus probably speeding the process as well.

PJM

QUOTE (Aristos Queue @ Mar 17 2008, 08:40 PM)

...Again, if you don't want clones, use .vit files...

Ok, so I gave a shot back to the old fashion way using .vit. Not considering that they are a pain to work with (can not instantiate instance when template is in memory) I think I will have to go back to using clone (with no tip strip ) because of performance issue. Basically the "Open VI Reference" takes about 800 ms to complete (and this is on a fairly recent machine [core duo]). This is really noticeable in the UI (The UI Opens copy of itself upon user action), and does leave the user with a "this UI is so sluggish" aftertaste.

Note:

• This UI (vit) is not big (~280Kb).
  
• For comparison, the "same" instantiation process with reentrant clone using a static VI ref takes 1 to 5 ms.
  

I think revisiting the "Tip Strip are not working in reentrant instance feature" would be a good thing. :2cents:

PJM

QUOTE (Darren @ Mar 19 2008, 04:48 PM)

...

Also, instead of the right-click > Open VI method, you can also have the diagram of a VI on the palettes open if you shift-right click to bring up the temporary palette (instead of just regular right-click)...

Can you elaborate on this? I am afraid I did not follow that explanation.

PJM

Your method is a good as any (probably the best one out there if you are using the project environement). As far as I know there is not way to instantiate a template from the palette.

PJM