PJM_labview

QUOTE (Darren @ Nov 20 2008, 03:40 PM) There is a faster way. Just temporary replace and existing VI already in the palette by the VI you want to drop. Once the drop is complete, restore the original VI. This works fine and it is fast enough. PJM

Use a system Label. PJM

QUOTE (Variant @ Oct 20 2008, 10:05 AM) None that I know of. Use a picture control if you want to have an arbitrary image displayed. PJM

QUOTE (rolfk @ Oct 18 2008, 01:13 PM) Ah, I knew that you would be the one that would have the answer to this one. This is good to know. By the way, when I upgrade the mesa.dll to a newer version, every 3D controls/widget (even on toolbar) are no longer rendered. Just though I would share this. Thanks again Rolf for the info. PJM

One think I will add that while the specifications (Software Requirement Specification) and the design description (Software Design Description) are usually different documents, the SDD is not a test plan. Typically, while the SRS defines "what" the software must do, the SDD defines "how" the system will be designed to implement the SRS. The SDD is the document that the programmer(s) will need to write/implement the code. The SDD does not define any test methodology or test vectors. Other document(s) (such as a test plan for instance) are used for this. Note (to the original poster): if you do some search on the web with SRS and SDD you will get some info about this. PJM

QUOTE (d_nikolaos @ Oct 14 2008, 10:53 AM) Decimate 1D array PJM

2.37 I was below 2 but I screw up on one of the triangle center. PJM

This should do it. PJM

I believe LV use an antiquated version of the mesa.dll to render objects in the FP and BD. This dll is located under your resource folder (in here "C:\Program Files\National Instruments\LabVIEW 8.6\resource\mesa.dll" for a typical installation). As far as I know this dll has been customized by NI (I might be wrong here) but there might be some functions available in there for getting emf images of objects. Hmm there is a wglGetCurrentDC in there; may be this could get you somewhere. Let us know how it goes. PJM PS: You might want to update your profile to indicate that you are using LV 8.6

QUOTE (JFM @ Sep 26 2008, 09:06 AM) If by CLI you mean Command Line Interface, then do you know that you can automate TSVN by passing command to tortoiseproc.exe? See http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-automation.html' rel='nofollow' target="_blank">here for more info. PJM

QUOTE (JFM @ Sep 24 2008, 10:36 AM) Good point. I never had a use case for that little guy ("always copy" primitive). I guess this does qualify as a use case PJM

QUOTE (JFM @ Sep 22 2008, 01:56 AM) What don't you do it programatically, this is pretty easy. Note: While writing a quick example for you I found a LV bug, so look at this http://forums.lavag.org/Buffer-reuse-gone-wrong-t12015.html' target="_blank">thread for the VI. This should be good enough (bug or no bug) for your use case. PJM

This bug is a little tricky to explain. First download the attached VI. Download File:post-121-1222274788.vi Now Open its BD and from there open the FP of "Get Image Subset.vi" and put each FP side by side. Step 1 Run the VI with the "White is transparent" flag set to FALSE. Here is the result: So far so Good (note: I highlight the structure where problem will show next) Step 2 Run the VI with the "White is transparent" flag set to TRUE. Here is the result: Somehow the buffer of the cluster is being reused and some data that should not be there are present. Note: at that stage there are no visible effect of this bug on the "Get Tree Symbols (LV86).vi". Step 3 Run the VI with the "White is transparent" flag set to FALSE. Here is the result: Now we can see the effect of the bug on the "Get Tree Symbols (LV86).vi". From that point on there are no non edit way to have this vi work properly. Setting the "White is transparent" flag to false always return an array of blank image symbols. Disconnecting the image data wire (at any place) and reconnecting it does temporary fix the bug until going back to the 3 steps. forcing LV to not reuse the buffer by creating another wire branch (see image below) is the only workaround that I have found. PJM PS: This bug is also present in LV 8.5 (I have not tried earlier version)

QUOTE (Aristos Queue @ Sep 23 2008, 07:54 AM) I think John solution works well for text with no formatting (using only one font). However as you pointed out earlier when you start to consider a string with multiple fonts and multiple formatting (bold, italic...) this is getting quite tricky. PJM

QUOTE (crelf @ Sep 19 2008, 10:13 AM) This got to be a first on LAVA (that I actually answer faster than you on a topic) ... PJM

Hi Shaun, Personally, I do not see the benefit to have one server in each location. I am assuming that you will have each IT department maintain each server location. If you really want to be in charge on the server (as opposed to use svn hosting) one will do just fine. You can have your user accessing the server over https. QUOTE I am not sure that this is the best way to promote reuse. Reuse components should be accessible to every developer (ie from the palette) when they are working on a project. QUOTE ...a separate repository for each customer we work with, or one single repository per site. In term of repository; you should consider having only one. You can have granular control over who access which part of the repository through defining the access right. QUOTE * Would there be any performance hit of having everyone working on the same repository (and would the associated large revision numbers be a problem) I never noticed any performances issues, but I don't think I ever worked on one with possibly more than 10 concurrent access. Good Luck (and welcome to LAVA) PJM

QUOTE (Attila @ Sep 19 2008, 08:43 AM) I would have to disagree. Not being able to do scripting in build application does not make it a useless feature. You can create countless of helper tools using scripting that will make your job as a LabVIEW developer a lot more efficient (just search that forum for several example of such tool). In regard to your particular use case, what were you trying to do? There might be alternatives in achieving your goal without using scripting. PJM

QUOTE (JFM @ Sep 18 2008, 10:28 PM) This is a good idea; you could even use the clone instance name as the queue name since it is already unique. PJM

Just to make sure, you don't have a release queue in the true frame of the upper loop right? PJM

Look Here: Can't get Word.Tables in Report Generation Toolkit in LV 8.6

QUOTE (Aristos Queue @ Sep 15 2008, 11:55 PM) Yes, I am working on an editing tool that need inheritance information, among other things, in order to generate the configuration files used to configure the classes. At the moment, this is not critical that it work without having the class in memory (this would be nice and faster if this were possible). Ultimately the editing capabilities will be built in the executable, hence the reason I am trying to have a way of doing it in the runtime engine. QUOTE (normandinf @ Sep 16 2008, 05:26 AM) Have you looked at this post from Darren about Inheritance hierarchy? The VI is password-protected but should work at runtime. I guess that's the output from LVClassPathFromInstance call you're looking for. I've used it to get the complete class hierarchy recursively. I don't have the result on my daytime computer, but could find it tonight. It's simply an implementation of Darren's VI with the tree control API from Norm the Captain. Ah, I search LAVA before I start this thread and I did not found this post From what I see I came up with a similar solution than Darren (using the linker info). I believe that this solution does not work in the runtime engine. About, the "LVClassPathFromInstance", this was just a side question to know if the Get LV Class Path.vi work in runtime (which it does). I am looking forward to see your recursive solution. PJM

QUOTE (Aristos Queue @ Sep 15 2008, 01:57 PM) Thanks QUOTE (Aristos Queue @ Sep 15 2008, 01:57 PM) Your question about the content of that VI's a password-protected block diagram I will decline to answer. I am not sure what you mean by that (because I did not ask anything about the content of the password-protected Get LV Class Path.vi). If you infer about how I get the info about the method name, LV 8.6 hierarchy window now shows CIN/CLFN info (see image below). My question about this specific part was just about whether this work in the runtime engine. I am more interesting in finding an answer about how to get the lvclass inheritance. Thanks PJM

QUOTE (Gavin Burnell @ Sep 15 2008, 12:54 PM) Good point. I actually forgot I now use/need the Get Class Inheritance for lvclass file path. QUOTE (Gavin Burnell @ Sep 15 2008, 12:54 PM) The lvclass xml file does appear to contain a class genalogy property which (if one could parse the binary data) might be the key.... Ya, I noticed that too. This what actually gave me the idea to try the linker info app.method on an lvclass file. PJM

I am trying to make a VI that can get a class inheritance paths from a LV Object. Additionally I want the VI to be able to do the following: Run in the runtime engine Get the inheritance without loading the classes in memory I got one way of doing it right now that involve this VI (LabVIEW Root\vi.lib\Utility\LVClass\Get LV Class Path.vi) and getting the linker info of the parent classes recursively. Unfortunately this would not work when build in an exe. There is a wiki article from Stephen Mercer on the LVClass Data Storage Format but this is more about the inherited class version that the inherited class path. Has anybody already achieved this? Thanks Side Question to Stephen: Is the call to LV.exe method (LVClassPathFromInstance) in the Get LV Class Path VI implemented in the runtime engine? PJM

QUOTE (TobyD @ Sep 9 2008, 08:58 AM) I will have to agree with Toby on that. Also, it has become so much of a second nature for me to use good style when coding (even when I am trying to be messy to use the diagram cleanup tool) that I hardly ever need it (I will try harder to not automatically do cleanup while I code). The few times I tried it, the end result required some more cleanup. About the multiple properties dialog, I could not agree more. This is indeed a time saver. PJM