Jump to content

Tomi Maila

Members
 View Profile  See their activity

  • Posts

    849

  • Joined

  • Last visited

  • Days Won

    9

 Content Type 

Posts posted by Tomi Maila

  3. Symbian support?

    in Mobile

    Posted

    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.

  5. Big Game Hunting

    in LAVA Lounge

    Posted

    QUOTE (PaulG. @ Apr 11 2008, 09:52 PM)

    I installed Safari after the 2nd or 3rd time iTunes wanted to update. It's not a bad browser, but nothing spectacular. I guess I expected more from Apple. I'll stick with Firefox.

    With my Windows XP safari seems to use anti-alialised fonts which are harder to read than fonts used by Firefox and IE :thumbdown:

  11. Installer with 3rd party DLLs

    in Application Builder, Installers and code distribution

    Posted

    QUOTE (rolfk @ Mar 28 2008, 11:17 AM)

    It's not a very good idea to install Open Source DLLs globally exactly because of the version problem and the fact that many Open Source projects reserve the right to make binary incompatible changes to the API even between minor versions. So someone else installing a newer version might break your app too.

    Instead copy the DLLs in question into the main directory of your application. That will always make your application use the version of the DLL it was built for and avoid any conflicts with other applications that might use a different version of your application, even if some other application had the great idea to install a newer and possibly binary incompatible version in system32.

    For .Net DLLs the GAC and the main application directory are really the only valid directories although LabVIEW allows to link to .Net DLLs by path name, but that will usually bring you into problem when distributing your app or otherwise when upgrading between LabVIEW versions, since they still try to figure out the best way to deal with that issue.

    It may sound a bad advice because DLLs were meant to avoid code duplication on the disk. But it is the way Microsoft also deals with DLL hell in .Net and considering nowadays harddisk sizes saving a few MB of HD space is a very bad excuse to turn yourself into dealing with DLL hell.

    And are you really saying that you are linking Open Source DLLs statically in your app? I find that a very bad idea unless you have some strong interest to hide that you use such DLLs. But even that usually won't work since the most popular license that would allow that (BSD) does require you to credit the use of such software in the doc and application such as in a splash or about screen.

    Rolf Kalbermatter

    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

  12. LV Project Woes

    in LAVA Lounge

  14. Stricly typed VI Server with Private data

    in Object-Oriented Programming

    Posted

    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

  15. LV Project Woes

    in LAVA Lounge

    Posted

    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.

  16. Installer with 3rd party DLLs

    in Application Builder, Installers and code distribution

    Posted

    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

  20. guys help me pleeeeeeeeease

    in Hardware

    Posted

    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

  22. Australian man killed by suicide robot

    in LAVA Lounge

    Posted

    QUOTE (SciWare @ Mar 23 2008, 08:24 AM)

    Perhaps this is a sign that there is a market for a Euthanasia toolkit for LabVIEW?

    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.

  25. Australian man killed by suicide robot

    in LAVA Lounge

    Posted

    I just noticed this story on the Register.

    http://www.theregister.co.uk/2008/03/21/ma..._suicide_robot/

    To make it short, an 81-year old Australian man built himself a suicide robot to commit a suicide. The robot worked as planned and shot the guy dead. I wonder if he used LabVIEW for the programming, I guess even 81-year old would learn to program LabVIEW with some practice. Or maybe Mikael & Kurt consulted him a little ;)

×
×
  • Create New...

Important Information

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

  I accept