John Lokanis

Doh! Well, in the end it turns out the bug is only associated with the 'Include Data Type' setting on control references. It has nothing to do with 'Strict Type Defs' afterall. Just confirmed that with the app support people. And the CAR# is 251234 for future reference. Hope this one does not bite anyone else. Luckily, I was able to find a workaround. Next time I will write my app in OOP and try to avoid these issues of getting data via VI Server methods. (this app was written a while ago when LVOOP was just a twinkle in AQ's eye...)

All I can do is show you this. Note the run continuously and that the include data type red stars are present and the version of LV is now displayed. Must be something wrong with your version of LV2009SP1 or mine. Can anyone else confirm this?

Ok, so removing the include datatype fixes the issue. And adding back the strict typedef setting has no effect. So my bug is the 'include datatype' problem. FWIW, the original with all the data types included and the strict type defs still works in 2009SP1 (this has been in my code since 8.2 and always worked until upgrading to LV2010) Here is the LV2009SP1 version where the datatypes are included and the typedefs are strict and it generates no errors. Variant to Data bug 2009.zip But NI did find a bug with the strict type defs. Here is the example from NI support where they demonstrate the strict typedef bug using simple datatypes: 7299252 Variant to Data bug.zip I might get two CARs out of this one. Nice...

In the process of investigating this, it appears that NI found another bug. If you try this with simple typedef'd datatypes, it also fails if the datatypes are strict. It works if they are not. Unfortunately, making all the datatypes in my example non-strict does not fix this. So, beware of using the Control Value.Get with strictly typedef'd datatypes. Still no CAR# yet.

It is looking more and more like a real bug. If I get a CAR# I will post it. Now I need to find a way to rework my app to avoid the Control Value.Get method for complex datatypes.

Just sent this one to NI but thought I would post here to in case anyone had any ideas. See the att zip for a simple example. It appears that the Variant to Data primitive *or* the Control Value.Get method does not like to work with complex typedef'd data. This used to work in LV2009SP1 but now give me error 91 in LV2010. Has anyone else run into this? -John Variant to Data bug.zip

You should not be seeing the & replacements when calling the web service. Try calling it from IE or Firefox and see if you still get them. I don't with any of my web services. This could be a problem with the tool you are using to call the web service and not LabVIEW. Any decent XML parser should know to convert < to a < character.

I have alway set these in my INI file: appFont="0" 13 dialogFont="2" 13 systemFont="1" 13 HideRootWindow=True blinkBG=000000FF thanks for the font info. I guess I will need to find a way to detect the OS and go from there.

It appears that the font used by system controls has changed between XP and Win7. As a result, some character graphics (progress bars using ||||||||) that I used in tables and MCLB system controls no long fit the same. Does anyone know of a way to fix this? Di you even know what the font (and size) was in XP and is in Win7? I poked around but could not find it. Sure wish we could embed data types and controls other than string in a MCLB or table. thanks for any suggestions. -John

thanks for the improvement ideas. I will give them a try. Perhaps this would make a good addition to the OpenG string functions?

you can import the snippet into LabVIEW and run it.

Wheel invented: Let me know if you can improve on this.

Before I go and reinvent another wheel, does anyone have a VI that will reverse a string but not esc'd chars in the string? For example, if my string is: find \[this\] text and I want to find it by searching from the end of my data first, I reverse it and the data before using match pattern. But the reverse is this: txet ]/siht[\ dnif what I need is this: txet \]siht\[ dnif because I need to preserve the esc'd special chars in the search string so match pattern works. thanks for any help! -John

I'm trying to get NI to hold the LabVIEW Object-Oriented Programming System Design class in the Seattle area thiswinter. So far, we have narrowed it down to the first half of December. But, we need a few more students to make it happen. If you are interested in taking this class, please let me know and call your Field Rep so they can coordinate things. Here is some info on the class: http://sine.ni.com/n...g/en/nid/205080

Here is a new one from me: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Place-case-selector-anywhere-other-than-the-middle-of-the-left/idi-p/1243440 Please vote!

I have to disagree with this. I only create product and have used scripting to do things I could not otherwise do. For example, in LV2010, you can now run a VI before and after you do a build (of anything). Well, since NI decided to not include a version number in a built LabVIEW Web Service, I added a function to my web service that returns my own version number. And, I created a VI that will (using scripting) increment the value that function returns. I then call this VI everytime I build the web service. Thus, I have used scripting to create an auto incrementing version number in something that had no version information at all before. This is very important in LV2010, since you can create a project that does not build any EXE but instead builds a web service and an installer to deploy it on a target. I am sure that over time we will find even more ways to add a little scripting into our code to help us build better deployable product. Just need to think a little outside the box (or sequence structure, in LV terms ). -John

I whipped out this tool yesterday to extract the call spec for any web services you have created in your project. This will make documenting your web calls much easier. I have tested this with all my projects that have web services in them but I would like others to give this a try and let me know if you find any bugs. I will be including this tool in my upcoming LV2010 web service tool package. The VIs are written in LV2010. -John Get Web Service Call Spec.zip

Ok, the issue with calling from c# was due to how the c# app was built. In order to make this work you need to set the platform properly in Visual Studio. Here is the explanation from NI: If you set the platform target as any cpu, your app willto treated as x64 on 64-bit windows. In this case, if you do not have 64-bit LVRTE installed, it will throw an error. However, if you do have the 64-bit run-time, but try to run the 32-bitLabVIEW built assembly, it will throw an error as well. So, you need to select x86 as the platform inyour Visual Studio project, which will allow you to run the assembly with the32-bit LV run-time engine. The support engineer promised to put this in a FAQ on building .NET assemblies in the near future.

Cool. As I mentioned above, the best thing would be for the 'build all' button to detect dependencies and build the specs in the proper order. That way, the order shown will not matter.

I suppose but I don't really like naming my build specs: a myapp web service b myapp exe c myapp installer Also, CAR #247090 has been created to track this issue. I hope it is not too late to get it fixed in SP1.

Looks like the issue is limited to 64 bit OSes. We got it to work on WinXP (32 bit) but it fails to work on Win7 (64 bit). I'll post a CAR if one is issued.

making them alphabetical and then sorting them will arrange them correctly. Then you need to change the sort to custom and change the names back again. So that is one work around. But an annoying one at best.

Already reported. I will post the CAR when they get back to me. I doubt the ctrl-click selection will work but I will give it a try when I can.

You might want to know about this bug before you upgrade. Also, beware of projects that create .NET assemblies. Oh, and every now and then, my IDE will switch from English to Chinese for no apparent reason.

I don't think so. I was told that the VIs do not persist from one call to another. And are all basically reentrant so they cannot cross communicate. Some new news: LV2010 cannot call a .NET assembly created in LV2010. This is a known CAR. Might also apply to LV2009. Not sure about LV8.6 or earlier. Also, I cannot call a .NET assembly build in LV2010 from C# either. It appears that the wrapper they add to the assembly is failing to detect the existence of the run time engine. Even on my dev machine. So, if you use .NET assemblies generated by LabVIEW, do not upgrade to LV2010 until there is a fix for this. Oh, and see my bug about the build spec order here before that one bites you as well...