Jim Kring

Purchase LV Application Builder: http://sine.ni.com/apps/we/nioc.vp?cid=10731〈=US More info about the LV Application Builder: http://www.ni.com/support/labview/toolkits...ild/default.htm

Here is something that might work for you. Download File:post-17-1102797995.zip

The Application Control library of the OpenG Toolkit has two VIs, which are useful for this: * Find VI with Focus * Find Frontmost VI

LabVIEW RT 7.1.1 is available at ftp://ftp.ni.com/support/labview/labview_.../Windows/7.1.1/

"illegal" might have been a little too strong. How about "not advisable, from a legal perspective". While, something might not explicitly be a criminal offense, you could still get sued for damages. A DDS attack is aimed at completely shutting down someone's business presence -- that equates to financial damages.

If you wire event data directly out of the event structure and to a shift register, when the VI is converted from LabVIEW 6.1 to LabVIEW 7.1, it will be relinked to different event data. This does not happen when the VI is converted from 6.1 to 7.0, or if the VI is first converted to 7.0 and then 7.1 -- only when converted from 6.1 directly to 7.1. Also, if you disconnect the data from the shift register, the problem does not occur. Download File:post-17-1102130800.vi *************** UPDATED INFO *************** Actually, I found the "real bug". An event structure inside a while loop with any uninitialized Shift Registers will cause the event data items to change.

Actually, it is not a DDS. It is not intended to overload the servers to the point that anyone is denied service. It is simply designed to consume measureable non-revenue-generating bandwith, which raises the spammers' cost of doing business. A DDS would be illegal.

Begun, this spam war has. (credit - Draakneuz, fark.com thread posting) Download File:post-17-1102089912.zip

Here's my "semi-universal" solution. Download File:post-17-1102054370.vi

I read this article on slashdot about a screensaver from lycos that "that targets known spam servers (taken from spamcop and verified by hand) with traffic in order to raise their bandwidth costs and hopefully price them out of the game." You can download the screensaver from here. The coolest part of the screensaver is the world map, showing the spammers' locations, some statistics, and the spammer that you are currently "attacking" :thumbup:

When you run VIs using the Run-Time engine, your not "running the source code". The only part of a VI that runs is the executable code. It just happens that VIs can have several parts contained within the *.vi file -- the LabVIEW application builder normally removes the diagram (source code). The LabVIEW Run-Time engine is really just LabVIEW w/o the compiler and editor -- it behaves almost identically. As long as all VIs in your "applications" hierarchy have been saved, they are compiled. All you need is the Run-Time engine of the same LabVIEW version, and your application will run. The "LabVIEW Application Builder" does not really "build executables", it simply aggregates your applications VI hierarchy into an LLB and then prepends an executable stub (<LabVIEW>\applibs\lvapp.lib) onto the front of the main LLB file and changes the extension of the file to EXE. Per the NISLA (since LV 7.0), NI reserves the right to make the sole determination as to whether your application is "authorized"; and, any application that competes with a National Instruments product is not authorized. So... does the "AppLauncher" breach the license agreement? No, not until NI tells you that it does (but they probably will). But, the fact that the AppLauncher is designed and distributed for the expressed purpose of bypassing the LabVIEW App Builder, which could hurt sales of the LabVIEW Professional Version and App Builder add-on doesn't help. Interestingly, any LabVIEW application (executable) can be used to run any other LabVIEW application (assuming that all VIs in the hierarchy are saved in the same version of LabVIEW). All you need to do is run the executable from the command-line, passing it the path of your application's top-level VI. -Jim

Did you know that if you change the file extension of <LabVIEW>\applibs\lvapp.lib from "lib" to "exe" that it behaves just like a built LabVIEW application with no VIs inside of it?

And, it's understandable that since it's your 1st posting to LAVA, you'd get it wrong :headbang: Some advice: RTFM, Learn how to ask smart questions, and try to be polite. :!: Are you here to learn, or here to burn?

NI's discussion forums (now powered by Lithium) are designed to create a community -- this community. Obviously NI has a lot of interests to ballance. The posting (in question) on LAVA is probably more of a detraction from NI's business interests, than it is a violation of IP/licensing. BTW, take a look at NI's new forums -- they look great. Cudos to NI for the excellent upgrade :thumbup: -Jim

Check this out... Microsoft has patented BASIC's IsNot operator.

I think that a good first step would be to have cross-platform support for JavaBeans and Java classes within LabVIEW.

Register for keypress events in the VI and then set the Value (Signalling) property of the appropriate buttons.

"Empty String/Path?" is very useful. Here is an undocumented feature of that function -- checking if a Variant is null. :thumbup:

I've noticed some File I/O problems when trying to delete files. It seems as if it is a permissions problem. Perhaps LabVIEW is locking the file and not releasing it, causing subsequent operations to fail. What does your code do, specifically? Can you post an example? -Jim

One would expect that the packet which generated the error would be lost -- that's what the error is telling you. Are you losing more packets which were sent without generating an error, prior to the disconnect?

In the units you specified, I think that the equation would be: Strain = (500 * Voltage) - 2500

Try OpenGOOP -- no passwords...

Here are some VIs that use system exec to execute the tasklist and taskkill commands. Download File:post-17-1098386155.zip -Jim

You need the OpenG Toolkit. The "List Directory" function works just like the primitive function, but allows a semicolon delimited list of file patterns.

:!: Today, I discovered a serious flaw in the following FlexMotion VIs: Wait for Blend Complete Wait for Move Complete Wait Reference The problem is that when an Error is passed into them they do not pass the "Board ID" or "Axis" values through, as one would expect. Here are some screenshots of the offenders: This can cause huge problems downstream. For example, here is some code that I wrote as part of a move command. If the move fails, I want to kill/abort the motion. But, since I no longer have valid "Board ID" or "Axis" values, the abort call fails (this is VERY bad :thumbdown:). You can see some code which is exposed to this flaw, below: The only suitable workaround is to not, use the pass-through values, as shown in the work-around below: Lucky for me, I didn't crash a motion axis before I discovered the bug.