chils

I am using MySQL .NET Connector with my LV2013 application which has been working fine for months. Today the new exe started requiring the user to pick the location of the MySQL dlls. Ironically, the dialog opens to the directory with the dlls in it. Currently, the dlls are in the /data directory. I have tried moving them into the same directory as the exe. I did see this post, but it didn't help. I haven't tried putting the dlls into the GAC because it wasn't entirely clear where in the GAC they would go, and in principal, having the dlls in the same directory path as the exe should be enough. It would appear this is something related to the OS because the exe works on the dev machine - just not the target. Any suggestions would be greatly appreciated. Chris

I am trying to integrate MS Expression Encoder into a LabVIEW 2009 application. I have attached the test code which includes a comment containing C code that should put the live video into a new window. I can get it to encode a broadcast via http but the delay is too long.Any suggestions would be helpful. Chris ExpressionEncoder.vi

Greetings all, My latest stab at the bleeding edge of LabVIEW capabilities has brought me to yet another question for which I haven't found an answer... Does the PDA module take advantage of the fact that Win CE is a deterministic OS or are thread prioritization and interrupt servicing isolated by the RTE from the OS? My hunch is that LV PDA doesn't make use of the deterministic capabilities of CE, but I really hope I'm wrong. Chris Practical Physics, LLC

Here is the summary from my NI post. If you follow the linkage in it you will eventually land at the slahdot discussion. While doing some research for a project I came across this post concerning the next version of the Microsoft OS, Vista, and its impact on OpenGL: http://forums.ni.com/ni/board/message?boar...d=58641#M136018 For a quick summary, the LabVIEW plotting routines are based on an open source distribution of OpenGL called Mesa. Vista will not be using OpenGL in a manner that will allow the high performance that OpenGL is known for. There are apparently ways in which OpenGL will behave well in Vista, such as running the OpenGL window full screen so that the Aeroglass desktop is not utilized for composing the window. My purpose in this post is to try to raise some awareness about the issue in the developer community, as tarheel_hax0r had tried to do, and also I would like to start a dialogue to get a developer wish list started for graphics upgrades. Since it would seem something fundamental may have to be changing with the LabVIEW graphics package in the next couple of years, this seems a good time to talk about things we have all wanted. I realize there is a feedback method to send these to NI, however, I am curious if those who would like to see some changes are in the minority or not. At the very least maybe someone from NI will let us know if are going to have to start learning DirectX/Direct3D. My wish list: 1. Hardware acceleration for all 2D and 3D plotting at least supported for nVidia and ATI. (The current win32 distribution of Mesa in LabVIEW does not support hardware acceleration) 2. Simpler plotting of (w,x,y,z) data - it works now, but it feels like a hack and anything 3D is slow without hardware acceleration 3. Assuming 1 happens, I would like to see buffering built into all plotting indicators with the buffer handled in the hardware Chris

I won't waste your time with all of the background for these requests. I have a more detailed post on the LV Discussion Forum under "Future of LabVIEW Graphics". For all 2D and 3D plotting: Let's have hardware acceleration functional for a minimal set of graphics cards. Let's have hardware buffering of data for the supported graphics cards. With the uncertain future of OpenGL in future releases of Windows, this seems like a good time to talk about finally making hardware acceleration functional. Chris