Tomi Maila

We can specify Mechanical actions for buttons such as Latch when released. The value of the button is reverted when the control value is read. However when using event structure with value change event with latch when released button, the value of the button doesn't revert back to original when reading the new value terminal of the event structure. Instead the control needs to be placed inside the event structure. Does anyone know why does the reading of the new value input not revert the state of the button? I've been wondering it for ages. In general the control BD terminal cannot be used to read the value of a control within an event structure as in general there may be multiple value change events in the event queue and the control terminal always returns the value of the latest value change and not the value change being handled by current event case. If the events are not properly handled in order, a state of the program may become inconsistent with the user actions. Instructing users to use the latching button terminals withing event structure guides users to bad programming habits that may result in bugs when used with fastly varying controls.

QUOTE (rolfk @ Apr 24 2008, 08:32 AM) The code tries to handle the byte order issue but it seems that at least in this one place I fixed, it was ignored. There may be other byte order bugs as well, I only used one type of TIFF image to test the code. Furthermore, be careful when using this code in a parallel application. The library uses LV global to specify the byte order of a single file. If multiple files with different byte orders are read in parallel, the code will fail. This would be rather easy to fix, but I didn't fix it yet. Maybe I will in a month or so as I need to start reading TIFF files for a project.

There was a bug in the byte order handling when reading 16-bit and 32-bit little-endian tags from a TIFF file. The byte-order in these cases was ignored and as a result wrong value was read from a tag. The problem fixed in the attached version.

I use the LV 8.20 introduced 3D primitives to draw 3D plots directly from polygon meshes. Using this method you can specify normal vectors for each polygon corner and the rendering will look smooth. Maybe not the easiest way but fits to our needs for 3D rendering of a brain.

QUOTE (sachsm @ Apr 16 2008, 04:28 AM) I just listened to this interview of Amstrong and I found it very interesting Thanks a lot for the link. -Tomi

Does anyone know if there has been any progress on the field of porting LabVIEW (real-time) to Symbian? Nowdays Symbian is a real-time operating system and would make a very attractive platform for mobile/portable LabVIEW applications, I think much more so than Windows CE. There are Symbian phones with WiFi, GPS, DVB-H, 3G, HSDPA , multi-megapixel cameras, multi-GB storage, biometrics, 3D graphics and tilt/acceleration-sensors. At the end of 2007 there were 141 Symbian phone models on the market. 77 million Symbian phones were sold last year. Symbian devices consume only a little power and would be ideal platforms for either remote controlling LabVIEW applications or as portable measurement stations.

QUOTE (PaulG. @ Apr 11 2008, 09:52 PM) With my Windows XP safari seems to use anti-alialised fonts which are harder to read than fonts used by Firefox and IE :thumbdown:

QUOTE (jaegen @ Apr 4 2008, 08:39 PM) QUOTE (NI website) No content exists for document id:6927 Well, maybe there just were no bug fixes

I would suggest avoiding mixing of red and green as there may be many red-green color blinds out there.

Now that the holidays are over, has anyone had time to test the Active VI Toolkit? I appreciate your feedback. p.s. I'll be in an achilles tendon surgery in the beginning of next week, so be prepared for some days of delays in my answers.

Will you publish the book in the internet?

Happy birthday Michael

QUOTE (rolfk @ Mar 28 2008, 11:17 AM) Rolf, thanks for your answer. Your guidelines sound good, however I'm not sure if I get everything to work as expected. Actually I've no problems to describe the issue in more detail to get maybe better insight into the issue. I'm building a LabVIEW VI library that relies directly on my own non-default build of an open source library A.dll and my own LabVIEW specific wrapper LV_A.dll on some of the functions on A.dll. The open source library A.dll then depends on two other open source libraries B.dll and C.dll and one closed source library D.dll. All shared libraries A, B, C and D are from third parties. I don't know how a windows DLLs calling other DLLs locates the other DLLs. The distributors of shared library A instruct to place B, C and D under Windows system directory and that is what I've done so far. When they are placed there A seems to properly find the DLLs. I would be more than happy to place the DLLs elsewere to avoid the possible linkage issues with wrong version of the library. Rolf, are you saying that if all the DLLs A,LV_A,B,C and D are in the same directory, say under vi.lib, then A.dll will load B,C and D from that directory and not a possibly different incompatible version from Windows\System32. I've understood that only one version of a single DLL can be in memory at once under Windows. Does this however mean that Windows regards DLLs with same name but different locations as different DLLs and allow as such to have multiple versions of the same shared library to be in the memory at the same time as long as they are located in different folders but can have the same name. So can I have for example two different versions of zlib.dll under vi.lib and under Windows\System32 at the same time and Windows would allow them both to be simultaneously loaded to memory by different applications. The picture below illustrates the dependencies of the libraries VI Library | / \ LV_A | \ | \ | A /|\ B C D

QUOTE (bmoyer @ Mar 27 2008, 10:19 PM) Your problem may then be the fact you installed LV 8.2.1 after 8.5. To verify test with a machine with clean install of LV 8.5 only. You can for example install LV on a http://expressionflow.com/2007/05/14/setting-up-windows-xp-on-vmware-server/' target="_blank">virtual machine. Also I think the AAxxxx are part of Advance Signal Processing Toolkit 7.5 so you can simply install that if you have it. It is easiest to install the toolkit after all LabVIEWs so that it is available on every LabVIEW version. Tomi

What about saving it as an XML? JKI could have a perfect solution for this.

LVOOP methods can be reentrant since LV 8.5 and also recursive calls are supported. About your problem, please check the lvproj and lvclass files with a text editor to see if they have problems with the file locations. I think I had similar issue previously where the file locations in the lvproj file were corrupted but didn't get fixed. I didn't report this as a bug so it may still be there. If that doesn't help, try pressing ctrl + run to force recompilation of everything in memory after which save all. Tomi

Just to make sure you did everything correctly. - Did you uninstall everything before reinstalling? - Did you install LabVIEW version in the order from oldest to newest? - Did you use the same LabVIEW version to open the project file as you created it with? - Did you install all the possible libraries and toolkits you might have been using for all LabVIEW versions? If you have done everything as described, please try to open the project file with LabVIEW 8.5. It has more advanced support for solving cross-linkage problems. Also try to open the project in another computer. It may be that your new LabVIEW installation has corrupted for some reason. Or maybe some DLL LabVIEW is using is corrupted.

Hi, I need to distribute a LabVIEW application that uses several open source shared libraries (DLLs). Some of the DLLs I can statically link to but the ones with LGPL license I need to distribute as DLLs. Now the problem I'm facing is that the there are practically many versions of the same DLLs out thereTthe problem arises when a newer version of the DLL is released. I don't want my old installer to overwrite a new version of a DLL that may be installed by another application. Also I don't want uninstallation to remove a DLL that is shared by other applications. So what is the best way to achieve these goals when distributing LabVIEW applications or LabVIEW VI libraries? Has anyone already solved the issue? Tomi

My five cents to the discussion.

This is bad. I made PJM's VI reentrant and dropped two copies of it on a block diagram of an empty VI. It appears that the events stop firing not only on the VI where the drag was initiated but on all other VIs as well :( I start drag in one VI and all the UI logic in all my other VIs will stop functioning properly.

QUOTE (rolfk @ Mar 24 2008, 02:43 PM) Well there could be at least two options. Either you could 1) query if the current handle is of subarray type or regular array type using some function call or 2) configure DLL call so that the datatype passed would always be a of subarray type.

Reemon, welcome to LAVA. I hope you'll enjoy your time here. As you may have noticed, we are a professional forum and expect our posters to follow the forum guidelines when posting. These guidelines are not there for your annoyance but to guarantee that the forum remains easily readable. Please also read the how to ask questions the smart way guide. When you follow the forum etiquette, you are about to get high quality answers. As for your particular question, I don't know the answer. However, your topic guys help me pleeeeeeeeeeeeeeeeeeeeeeeeeeeeeese does not certainly attract anybody to read your post. Good topics are informative so that readers can choose which topics they read. I guess you're not a native English speaker. However try to spend some time to formulate your question in an understandable way. As a translation for the other readers I think Reemon wants to ask if this particular GSM modem can be interfaced with LabVIEW. I think this topic would fit better to the hardware forum as this is not actually LabVIEW language related. Michael, would you please move this post to the Hardware forum, where it belongs. Reemon, even with some problems in the post, please do not repost your question. You can answer your own topic, if you choose to, and try to rephrase your question in more understandable manner. Again you are wellcome to LAVA and hope you enjoy here. Tomi

The attachment name Drag Bug gave me the impression of something like this.

QUOTE (SciWare @ Mar 23 2008, 08:24 AM) I guess there is also market for products from other companies. Lego could release a simple robot toolkit with some predesigned models LEGO LST. Sony could release a new toy robot with the brand My Last Sony.