PJM_labview

QUOTE (tcplomp @ Apr 10 2008, 11:48 AM) 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) 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) 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) 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) 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

QUOTE (crelf @ Mar 18 2008, 12:11 PM) Well if I have to choose, I want a working app with a pretty intuitive UI. PJM

QUOTE (Aristos Queue @ Mar 17 2008, 03:34 PM) Ok, then, the documentation for Tip Strip is lacking since there is nothing about it not working in reentrant instances (See screenshot below of LV 8.5 help window for this)? http://lavag.org/old_files/monthly_03_2008/post-121-1205802109.png' target="_blank"> One can argue that there is a bug in the documentation (at the very least). There should be a line like "Available with reentrant instances --> No". I was not aware of these limitations of using reentrant VIs as reusable UI, but since this is the case, where can I find a list of all the properties (and methods if any) that do not work in reentrant instances? PJM

While this is a documented error (since there is a number for it) I believe this is to be bug. If you try to change tip strips of controls located on an instance of a reentrant VI you get that error (1446). I have no clue as to why this is not possible and I am considering this to be a bug. Note: Attempting the same operation on the "Master" copy of the reentrant VI does work. PJM Note: This issue is present in LV 8.2x and 8.5.

Liz, Just as an example, I did some more cleanup of your last attachement. I did not made any functional changes whatsoever. A good house keeping rule is: remove everything that distract from understanding what the code do. Very often this end up meaning keep wire straight, remove unnecessary bend in wire, align primitive when possible etc... You might find this usefull. Cheer PJM

QUOTE(JDave @ Mar 4 2008, 10:00 AM) Oops sorry, I though that this was what you were talking about. I missread. QUOTE(JDave @ Mar 4 2008, 10:00 AM) Have you gotten behavior where the only running VI is a System VI and this causes the Getting Started window to appear? I can't seem to get that behavior with System VIs. I had one System VI running (shown or hidden) and nothing else open. Still the Getting Started window never showed up. David Is you background service FP close? PJM

QUOTE(JDave @ Mar 4 2008, 08:31 AM) This is odd. I have never noticed any issues with this. I used it quite a bit, and it seem to always work for me. I think NI is using it in the navigation window, and as far as I know, I have not heard people saying that it does not display the image of the right VI with focus. QUOTE(JDave @ Mar 4 2008, 08:31 AM) ...Assuming a background service, however, it would be expected that if all other VIs were closed then the Getting Started window would appear. The service would not stop, but remain hidden. If the user closed LabVIEW, the service would also close automatically. Is this even possible? Yes this is possible. Here are a couple items that help in doing this. 1) The close if lonely does generate a scripting event (I forgot which one at the moment) which you can catch and act upon. 2) System VIs, while not shown in the hierarchy, could be used as well for this background service if they are the only one left running in memory. PJM

QUOTE(crelf @ Mar 3 2008, 11:53 AM) Ok, I'll bite. I Agree to the post above my answer, basically that this would be nice to optionnally be able to have a Runtime engine webinstall if the target machine does not have it already. PJM

Absolutely! I could not agree more, PJM

QUOTE(Justin Goeres @ Feb 25 2008, 12:44 PM) Hmm, interesting tought... Now that you mentioned it, I wonder if there is a similar purpose behind the "ridiculously" large class icon... http://lavag.org/old_files/monthly_02_2008/post-121-1203994107.png' target="_blank"> PJM

One of the thing that could bear some improvements is the error message one get when trying to run a software that does not have the LV runtime install. It goes more or less like this: "myexecutable.exe" requires version 8.5 (or compatible) of the LabVIEW Run-Time Engine. Please contact the vendor of "myexecutable.exe" to correct this problem. This error is really not usefull to the user of the software (it is conceivable that they do not know what is LabVIEW). If the message was more like: "myexecutable.exe" requires version 8.5 (or compatible) of the LabVIEW Run-Time Engine. Please Click here to download an install it. This would be a lot more usefull. Just my two cents PJM

Just to add one more point to this conversation. While the cluster size is reset to its default size it also has the side effect to hide back all the Labels. Strict type def cluster are not necessary huge. If I have a very large strict type def cluster and I do not benefit to see a large constant on the BD, then I wrap it in a SubVI, but quite often I want to see the cluster constant and its labels for documentation pupose. So if you happen to "improve" on this particular behavior, please do not forget to preserve all aspect of the constant (labels visibility included). PJM