Rolf Kalbermatter

Chris has pointed out that the original only states an observation and doesn't actually maky any characterization. But to get back to your reasoning, it is actually not about mentioning Nazi or Hitler that is the bad thing, it is about using those terms to compare some perceived or real action of someone with it. Those words are very loaded and using them to compare anything with, is usually simply a way of trying to say someone is an a**hole without actually using the word. And as such extremely unpolite, totally uncalled for and most definitely not helpful in the bigger context of a discussion. If you want to talk about genozide, race discrimination and despotisme, then I do not see why you couldn't use Hitler or Nazi in that context but you shouldn't try to use them out of context for something else. Rolf Kalbermatter

For this you need a reference to the Block Diagram. Then one of the properties of the Block Diagram is "Highlight?". And this seems LabVIEW 8.0 only. So you will have to tinker with the Object Creator tool posted elsewhere on this board. Rolf Kalbermatter

I said BEFORE :laugh: and I verified it's before 7.0. So what you were experiencing is probably anothere issue. You can check the issue by typecasting the refnums into int32. If the value of a refnum changes between repetitive executes of the VI then it is a refnum that needs to be closed explicitedly in order to avoid memory leaks during execution of the VI. Note that LabVIEW does dispose of refnums anyhow as soon as the top level VI goes idle so if you are not creating refnums over and over again in a loop you are not exactly in deep shit, it's just not a nice and welbehaved application. Rolf Kalbermatter

Image processing on PDA is mostly like Formula 1 racing in an old VW "K

It all depends on LabVIEW versions too. Before 7.0 (or 7.1 I'm not exactly sure at the moment) it was imperative to close all references always no matter how you got them. Since then you need to close explicitedly opened references only but as a matter of good style closing all references anyhow properly is always a good idea. LabVIEW will know about those that don't need to be closed explicitedly and just execute a NOP instead of the close operation. This saves you the headache of remembering (or experimenting) what needs to be closed and what not. Rolf Kalbermatter

Not sure if it serves your karma well, to try to get him to pest other boards . But I've added an alfa filter to my perception already so not sure what you are replying to exactly. Rolf Kalbermatter

LabVIEW is highly parallel in execution. Unless you do not provide data dependency the execution order of code is totally random. In your case this means that the Read function can execute before the Write function is executed. In that case you never will be able to read the value you just wrote! Another problem is probably the amount of data you read with the count character! You typecast an int32 which will result in 4 characters being written and then you should read 4 characters too. Last but not least the serial port settings will terminate by default on carriage return on read. Since you are writing binary data the decimal 13 character can happen anywhere in the data stream and the default setting will sometimes terminate on that character on Read instead of returning all 4 characters. Rolf Kalbermatter

Not that fish & chips is considered top notch culinarian in the rest of Europe And the few times I've been to England and tried it anyhow to test if it was still true, I never was very much impressed by it. To soft and tangy chips! I mean it is usually eatable but not something I would make a trip for. For that I would need something lake Clam Chowder and of course in San Francisco Or should that be some delicius fish meal in Cairns? Of course the French and Italian cuisine is never to be forgotten and nice tasty spare rips in Austin are also great. Rolf Kalbermatter

Having done some work in Wine and knowing the structure of the Wine code a bit I have to say that having a full source installation of said has helped me quite a bit. Not necessarily easy to find a particular function if you do not know where to look for but about how to achieve a lot of things. Wine code is usually good structured and rather high quality so learning from there is definitely not a bad thing. Rolf Kalbermatter

It's not so much that I wouldn't think NI may like to do that, than that I don't think they would even dare to try Back when I was there they probably wouldn't even have thought about it, or at least if someone thougt it he never would have spoken it out, yes. Nowadays they are so big they have to watch a bit what they are doing, otherwise they may get hit on their fingers for being a naughty boy. Rolf Kalbermatter

Ouch , that is worse than eternal hell! Rolf Kalbermatter

1.7.1 is an old version of NI-Serial. That software however is only used when you have specifically installed serial boards from National Instruments. It is NOT NI-VISA but provides the drivers for the NI serial boards to be visible in Windows at all. NI-VISA sits on top of the Windows Comm API and is necessary to access any serial port (not just on the NI boards) from within LabVIEW. Rolf Kalbermatter

If you know the function name such as in this case it is very simple. OTherwise it is indeed hard to find something because of the sheer amount of information on that site. I little to borad of a term and you end up with thousends of links and usually some rather obscure ones (at least for people mainly interested in Win32 API) on the top. For browsing more lasurely in the Win32 API an installation of the Microsoft SDK is quite handy. It is not talking about every possible MS soft but concentrates on the Windows API and family. Rolf Kalbermatter Actually Win95,98,2000 are usually on the same page if it is about Win32 API, or lets better say it sometimes still states that certain functions are available in older Windows versions. Microsoft is slowly getting mentioning of old and unsupported OS versions out of the docs when revisiting such said docs. What I usually end up finding when looking for a particular API are the function descriptions of the Windows CE APIs in tenfold on the top of the found links before I sometimes get the link to the REAL API. Rolf Kalbermatter

I have been upgrading to 8.0.1 about three weeks ago and haven't noticed anything strange in LabVIEW 8 yet. The mass compile did take about 3 hours despite Jim's accelarted tool, but that is probably the price for having a Centrino notbook with a 1.6 GHz Mobile Pentium. Considering that after more than one year I still can work almost 4 hours offline on one battery I guess that is not to bad. Rolf Kalbermatter

I wouldn't really know and if it was me I wouldn't probably discuss it. It can be harsh to feel censored but discussing this on some unrelated place does usually not help. Rolf Kalbermatter

I have to admit that my first reaction when reading this post was, shit this can't be! But above mentioned statement about deleting any posts about deficiencies in LabVIEW 8 made me lough and check for the date of the post Still I think it is quite a good April fools joke and without that statement about deficiencies I could have probably went through the entire post and still believed it at the end. NI having total control of the Developer Forums can remove any post they feel is not appropriate and they do sometimes do this not just for totally out of context posts or spam but also some posts about things NI does not feel the general user group should know about. I think I'm missing a post or two as well somewhere on those forums. Well, maybe it just got accidentially lost when porting the forums over from one software to another. The last porting two years or so ago, made searching in older posts really sometimes impossible. Rolf Kalbermatter

As a former AE (in a long ago life) I can really relate to his feelings ;-) But I was considering checking out labviewforum.de once, but your comment makes this sound like an utterly painful experience. Rolf Kalbermatter I think the problem with your project duplicator is more one of many advanced LabVIEW users not really having made the jump to 8.0 already. I for one still do most of my work in 7.1 and even sometiems 7.0 as there are projects that need simple modifications that do not justify the hassle of upgrading (and veryfying every aspect of the application to still work perfectly). Just starting to work in 8.0 for the first time for real for a project and in fact only because the client has a .Net library he developed himself which uses .Net events. Otherwise I would most probably have used 7.1 too for this project. The whole project management in 8.0 is a really big change of work procedure and might be fine if you start with LabVIEW but can be a little bit of intimidating if you have managed to work with LabVIEW since version 2.2.1 without this goodie. Rolf Kalbermatter

The 3D control is Active X but the 3D Picture Control is an extension to the well known Picture Control implementing some 3D object drawings, using the OpenGL extension LabVIEW has been linking to for several versions now to implement their new (and IMO ugly) 3D control style. The extension to the Picture control is really available since 7.0 but NI only released a Beta-Test Toolkit to make use of it with LabVIEW 7.1 and being marked as a Toolkit LabVIEW 7.1 refuses to safe it back to 7.0 As to 3D programming in LabVIEW I'm afraid I won't benefit much of such a feature. My left eye is basically lame so all those 3D hypes in the past were leaving me with some curiosity as to how 3D visisbility would really look like. Rolf Kalbermatter

Does your server handle multiple incoming connection requests simultansously? If not it may be not able to get into the listen queue before the timeout occurres. Or one of the sockets either on the client or server sides is not disposing closed IP ports properly so that the socket library runs out of port numbers after a while. 4 second interval would result in about 1000 connections per hour and therefore 1000 used up port numbers so this might be a possible explanation. You could try to log the used port number of your client (and server) and if it keeps increasing instead of reusing the same few port numbers then you might have a problem of not properly closed TCP/IP ports. Could it be that your TCP Close function gets wired with an error cluster indicating an error which might prevent the close from completely closing the port. I know Close functions are supposed to close independant of the error in status, but I know that some functions in the past didn't do that always. Another issue I had sometimes with similar symptoms was when using DHCP. There I have to say that what I did was actually keep connections open for a longer period of time and if the IP address of one of the sides changed during that the connection just went into nirvana. Writing to it did nor produce an error nor get the data arrived at the other side, which also still believed it had a connection open. Closing/reopening connections solved that problem more or less but changing to static IPs was what made it really reliable. Rolf Kalbermatter

LabVIEW (and Windows 95 and higher) being a 32bit application you only can use 32bit compiled DLLs. That means that int is really a 32bit integer. Configuring the Call Library Node to use int16 instead will create some serious problems. For the skalars you won't see crash but just some strange and truncated values. For the array this certainly will cause serious trouble including invalid pointer accesses and crashes since the memory area you are telling LabVIEW to pass in will be only half as large as the DLL thinks it should fill in. Also I hope you make sure that the two arrays are preallocated in LabVIEW to the necessary size. In calling DLLs the caller is ALWAYS supposed to allocate memory for the DLL funcitons to fill in their result. For your case this would mean that you have to allocate two arrays of 10 * 10 elements to pass in. Another issue is the use of two dimensional C arrays. This is an area in C where the specification is not always very clear. A C compiler usually will create an array of n * x elements and internally treat it as one dimensional array which happens to be the same way as LabVIEW looks at multidimensional arrays. But it also can sometimes mean that you have an array of pointers each pointing to a different array of elements (which is not very simple to create in LabVIEW at all). Of course doing Matrix multiplication entirely in LabVIEW is another solution, if done right not really slower than doing it in C too. And LabVIEW 8 has additional support for Matrix operations. Rolf Kalbermatter

The description you are mentionening seems to be for Visual C 6.0. For Visual C 2003 or similar you will have to replace some of the keywords in $(keyword) with something else that has changed between Visual C. Sorry can't help you here as I'm still using Visual C 6 and for that matter when creating a CIN, which by the way is considered legacy technology and therefore not recommended for new designs, I'm using the nmake command on the command line instead. That whole Visual C IDE business for creating CINS seems simply overkill and to much hassle to me. If you are trying to develop something new I would recommend you to abandone the CIN route althogether and go with DLLs/shared libraries instead and link them into LabVIEW through the Call Library Node. CIN support is probably not going away soon in existing LabVIEW platforms but support for new and upcoming LabVIEW platforms (Win 64bit, MacOS Intel, etc) is likely to be non existent). Rolf Kalbermatter

But it is the case! The Windows extended properties for a window determine if the window will have a taskbar button or not. And I do not see why you couldn't make this test yourself. It is really simple and asking for a ready made example sounds a little like a HH (homwork hustler). Rolf Kalbermatter

Just try "LabVIEW" as library name. It might work in the built application but there is no guarantee. The special LabVIEW library name was introduced in probably around 5.0. Not sure if LabVIEW was already using it as a place holder for the current instance or if that was only added later on. There is probably quite a lot more than a single Windows API call behind SetDefaultPrinter. Printing in LabVIEW is somewhat involved and the original idea was to hide as much as possible of the printer setup and configuration from the user. This makes it now a little difficult to provide full print control. And the reason this name was changed in later versions is probably because it had a name clash on one of the platforms LabVIEW is compiled for. Rolf Kalbermatter

As the original author of the OpenG Pipe source code I can only say that the code as present now is still an alpha work in progress. I haven't found much time to go deeper into it and just got it so far to work somehow under Windows although there needs to be done more testing and also the Linux and MacOS parts would be nice to have. What might be the problem with LabVIEW 8 I have really no idea. Pipes under Windows at least are a somewhat fragile technology with lots of possible problems and it is very well possible that LabVIEW 8.0 does something with the Command Line Console for its own internal dirty work that might conflict with trying to redirect standard IO to pipes. I haven't currently any time to dig deeper into this so anyone with some C programming knowledge feel free to investigate what might be the problem. The code comes with the source code for a simple command line executable that can act as loopback device so it is definitely a good idea to try to make the DLL work with that example under LabVIEW 8 first. If this works but not with PErl then it is likely that Perl does some weird stuff too that clashes somehow with LabVIEW 8. Rolf Kalbermatter