Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation


About Bab

  • Rank

Profile Information

  • Gender
  • Location

LabVIEW Information

  • Version
    LabVIEW 2010
  • Since
  1. Thanks for the reply. my problem was that I was getting the proper string out of the WinAPI call, but with a NULL character at the end and I expected that GetValueByPointer would return just the string, without the Null character. I am not sure if GetValueByPointer always react like this. Is it the expected behavior, or a bug? As an alternative I now use 2 Call Library Nodes: StrLen to get the string length, and MoveBlock to copy the CString into a Labview wire. I attached the resulting vi for the function GetUniversalName (discussed in another thread on LAVA...) It converts a path to a mapped network drive (ex: S:\folder2\file01.ext) into its UNC name ( ex: \\server1\share1\folder1\folder2\file01.ext, if S:\ is mapped to \\server1\share1\folder1). The MoveBlock function properly truncates the CString an does not return the ending Null character The GetValueByPointer returns the complete CString, including the ending Null character - which is not what I want here... I hope someone finds this useful. PathGetUniversalName_no_Sub.vi
  2. Dear Rolf, thanks for sharing your knowledge! I am actually using the GetValueByPointer xnode in order to get the string returned by a WinApi call. Strange enought, the string coming out of the xnode IS Null terminated. That is I am getting the \00 character too. I did expect to get all the characters BEFORE the Null. I am interesting in using the code you shared as an alternative, but how do I use it? It looks like ShaunR knows too how to use it. Do I have to create a new C dll? Does it have to do with CIN? Or maybe you could point me to a topic where is is explained. I also have trouble understanding how to use the "LabVIEW Manager Functions" described in LV help (http://zone.ni.com/reference/en-XX/help/371361H-01/lvexcodeconcepts/labview_manager_routines/). What do I need in order to use these? (MS Visual Studio?, NI CVI?) What are you using? Thanks for any assistance. BaB.
  3. Hi Jason, somehow I never get any notification even though the thread is marks as being followed by me - I should ask in another thread... To be honest I am not sure I understand your question. The input variant wire "type" contains the "names" of the elements embedded (number, string, cluster, etc...). It is used to read the proper keys - and this works perfectly now. The problem is that the output variant (labeled "key-value") is not of the same type as the input variant: the names are missing or wrong. I am posting the screen-shots from the original post from openg.org, since the picture are not displayed unless one is logged in openg. It does not point to the root cause but shows an example of undesired effect. Here the Section Formatted Cluster contains a cluster with 2 elements: a string named "value" and a number with no name. It is expected that the string would have the name "Name" and the number the name "Age". When trying to get the "Age" element, nothing is found! -> the workaround I have been using: ! This is not the final fix that I suggest. Fixing the root cause "Read Key(Variant)__ogtk.vi is the proper way (as discussed in the original post with Jim Kring) The expected result look like this: Now the elements of the VCluster have the right names and Getting the "Age" element out of the VCluster is working! I hope I am not confusing you here. I understand you are writing tests vis for Read Key(Variant)__ogtk.vi. Should I send a vi with my suggested fixes? Can I see these tests, are they in the openg repository? Cheers, BaB
  4. Thanks for the reply, somehow I missed it. I thought I should get an email since I am following this topic - is there something extra to activate? JG: did you create a bug id in the bug tracking system? It would help ensure the issue is not forgotten again.
  5. Hi I signaled this issue about 2 years ago: http://forums.openg....?showtopic=1088 Basically, for some data types, the variant name from the input is propagated from the variant input, and for some other data types it is not propagated. The use of the LV node "To Variant" creates a variant with a standard name (the name of the input wire, ie no name or sometimes "value"). example: Integers I8..I32 The same is true for [u8..U32], [sGL..EXT], [CSG..CXT], [boolean], [string, DAQ], [Path] The other data types: [Enum U8..Enum U32], [sGL PQ..EXT PQ], [CSG PQ..CXT PQ], [Array] and [Cluster] seem to propagate the variant name. I have not tested the vis, but by looking at the code it looks like it. example: I see 2 possible fixes: 1: using the OG SetDataName function: 2: using the NI FlattenedStringToVariant primitive and the TD of the input variant. This is the same that is used fo the PQ data types ([sGL PQ..EXT PQ] and [CSG PQ..CXT PQ]). Solution 2 might be faster because the proper variant is created in one operation. In solution 1, the variant is first created and then modified. Anyone has an opinion on this? How can this fix be integrated in a future release of the package? Can I help? And by the way thanks again for these great tools! BaB ------------------------------------------------------------------------------------------- (I wanted to write the following as separate post but using reply just merges the reply with the original post... strange....) As a side effect of the fix above, the Cluster case could be modified: When the vi propagates the data names for all data types, there is no need to explicitly set the name again after the recursive call. A second note is that the Cluster Name can be set directly with the optional input to the "Array of VData to Cluster" function, and the last SetDataName function to the right could be removed too.
  6. I know the thread is pretty old, but I am being struck pretty bad with this bug. The bug (CAR 277004) is in the list of the bugs fixed in LV2011. But I am not planning to upgrade my projects to 2011 now. I have recently converted a project from 8.5.1 to 2010SP1 and another one from 2009 to 2010. I have a simple vi which illustrates the bug: I created it in LV821, then opened it in LV2010SP1, marked the vis a "separate compiled code", and saved them. Now if the typedef enum is modified (item added or removed), the constant gets corrupted when it is opened again and the object cache exists. If I clear the object cache, then the constant is back to the correct value on the first open, but on the second (the cache exists again) it is wrong again. If I create the same vi from scratch in LV2010SP1, the bug does not occur: no corruption when modifying the typedef. Even more interesting: I delete all the code from the block diagram in the vi converted from LV821, and save it - I have an empty vi!. If I create the same BD in this vi, with a new typedef created in LV2010SP1, the file gets corrupted in the same way as explained in the beginning of this message. -> I conclude that the typedef itself is not responsible, but some trace of the vi with a typedef enum having been converted from an earlier version of LV to LV2010SP1. Unfortunately these new findings do not show me oh I could "uncorrupt" my many vis with typedef enums which have been converted from earlier versions of LV. I suspect If I copy the code from the corrupted into a blank LV2010SP1 vi it would fix the vi, but it looks like a lot of work since a vi is not only a BD (FP elements, vi properties...) Have anyone found more info on this issue? Is there any known workaround? Rob Calhound: how did it go with LabVIEW R&D? Did they find any other way to avoid the bug other than making the VIObjectCache read-only? I have a support request with NI, but they don't have much info on it right now. I wish I could get in touch with the engineer who fixed this in LV2011 - he would know how to avoid or even fix this issue...
  7. Thanks Darren that is exactly what I was looking for. I searched in the VI properties and methods but not in the Application methods and properties...
  8. Hi, since Labview 2009 and maybe before, the VI Properties dialog shows the "Source version" of the vi (Category "General"), that is the Labview version last used to save the vi. If the vi was last saved with labview 8.2, it displays "8.2", and for LV2010 it will display "10.0". Does anyone know a way to get this information programatically using a property node for example? cheers, Bab
  9. Hi, just some thoughts: you could google on visual basic scripts (VBS) and getting device manager info. There are some objects (activeX) available in a standard windows installation which are commonly used in windows scripts to retrieve this type of information. I have read threads about getting installed software information, managing services, or getting users and groups information. It certainly allows looking at the info found in the device manager. It is called Windows Management Interface (WMI). Since it is activeX, you should be able to "translate" examples found for VBS into G code. I hope it helps getting in the right direction. Cheers.
  10. Hi, well I use branches when upgrading Labview. First I make a new branch with the previous version of Labview (a copy of the Head revision of trunk), without switching to the new branch. Then I mass compile my working copy in the new labview version. I test it a little an try to build, then commit the changes onto the trunk. My repository looks then like this: Project1 ---- tags ---- ---- [...] ---- branches ---- ---- LV7.1 ---- ---- LV8.5 ---- ---- [other branches...] ---- trunk note: trunk now contains the LV9.0 Vis. It works for me. I don't think I need anything fancier since I usually won't development or maintain the branches with old labview versions (they are actually more like tags...). As for your examples, example 2 does not look so good in my opinion: you loose the history by using different repositories. Any other suggestion anyone? BaB
  11. QUOTE (Antoine Châlons @ Feb 6 2009, 01:46 PM) Hi Antoine, what about using the "Mouse Leave" event? If the mouse button was down as the mouse left the image control, then it is likely the ROI was being modified. Just my thoughts on your issue... A+ BaB.
  12. QUOTE(Yen @ Dec 4 2007, 06:06 PM) Hi Yen, I feared I would have such a reply. Jim Kring’s topic Is there a cluster frame color property? indicates the frame color (for a cluster or any other control I would say) is not available programmatically. I naively supposed that every manual change available with the right mouse click on a control was also available using property nodes… And to answer your question Yen: your example of a Boolean is one of the control that have a color property, unfortunately it is more an exception that the general case. Let’s look at a simple digital numeric control. When you edit it in the control editor, it has 6 sub-parts: Name Label, Numeric Text, Increment, Decrement, Radix and Frame. The first 2 are nice since you can get a reference to it and they belong to the Decoration\Text Class and inherit therefore the colors property programmatically available. The 4 other seem not available at all programmatically. The Increment and Decrement parts are like simple buttons having each 2 states (and thus 2 colors each). The radix has a background and a text color. The frame has also 2 colors. So you see how many thing you must modify in order to set the colors of one control the way you really want it. If you have many controls – maybe in a settings window with many tabs… And if you have a rather large application with many Front Panels. It takes quite some time. If no one know of a way, I guess I’ll be able to automate the coloring of Booleans and Text-Class Objects at least. I tried to typecast a Digital Numeric into a Decoration: but I only get Error 1058 (Specified property not found). Thanks, BaB.
  13. I am wondering why I can’t find the „colors“ property for the control class objects? If I want to update a Front Panel and switch from the default LabVIEW colors, I need to use the pencil tool and edit all the “parts” of all the controls and indicators. It gets even more tricky when one control “part” has several states with a color each (i.e. the increment and decrement buttons of a digital), then I think the only way is to open the control editor (Customize option), and change each color. So I NEED to automate this task. Did anyone ever need to do just that? Is there a way to manipulate controls, and sub-parts of controls? Maybe any idea in the direction of programmatically manipulating the control editor? Can I get a reference to a control sub-part (say the frame)? Thanks, BaB.
  14. QUOTE(Justin Goeres @ Sep 10 2007, 07:25 PM) an alternative, more simple but completely free ist the "multimon" utility that I have used several years. You get a task bar to your second monitor, and the icon in the title bar to send a window to the other monitor. link: http://www.mediachance.com/free/multimon.htm give it a try... BaB
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.