DF exit

[ekanderson]

at least for DFExpress 5.79A, if you haven't modified sequences, etc.

but HAVE collected data.

Inadvertatly clicking the Big Red X, DF exits without warning.

Virtual channel data is lost. Cannot use channel type test, so PLEASE don't suggest that.

OR allow 16 Test channels.

[AzeoTech]

Data (even adding to a v channel) is not considered a document change and so doesn't cause the system to think the document has changed.

If you do:

system.HideSystemMenu()

cd\

from a sequence it will cause the x and all the other buttons in the title bar to go away. This will prevent a user from hitting X and is actually designed for this. You probably should then create a button on a page somewhere that does:

system.quit()

In non-Express versions you can do:

system.savedocument()

just before hand as well, but if you are going to use Express, you'll probably just have to create your own message for confirmation, say using system.messagebox().

[ekanderson]

OK, got that

As far as I can determine, to get page capture I have to spend $700.

To get document save I have to spend $50.

Is their anyway, other than your matrix, to get a clearer understanding of which "level" of DF gives what features.

I'm hesitant to purchase a product that has to have a "Key" to function. Historically I have had VERY BAD LUCK with such.

If I have a drive fail (about 3 times in 30+years), I need to replacement it, or try to transfer the application to another functioning computer and remove it from the original installation computer. Which, if the original's drive is Kaput, is impossible.

I realize that you have to protect your software, but it shouldn't be at the expense of the end user. Especially when they are fighting a crapped out drive.

For LAN networked computers, you should allow DF to be installed on any/all of them, but allow it to only run on one of them.

[AzeoTech]

The only way to find that level of detail between version is to review the help file.

As for the unlock "key". We use this distribution method because we have customers all over the world and shipping is quite expensive to many places. If your harddrive fails, you can simply use the unlock key again to unlock the new computer. There is a limit on how many times you can do this before you have to contact us, but we are not trying to make things difficult for you, but simply provide a simple way to distribute our software worldwide.

Anyhow, if you go to the store and buy a boxed version of say, microsoft office, and then lose the CD or have it eaten by your dog, I severely doubt you are going to be able to get Microsoft to send you a new one. At least with DAQFactory, all you have to do is download from our website and use your unlock key. If you purchase with a credit card through our ecom system, we even store your unlock key for you and you can access it at any time by logging into MyDAQFactory (through the support page).

I think you've just had bad experiences with software companies that are overly fearful of software piracy. We certainly don't want you to pirate our software, but we believe that you can go to far. We'd rather have happy customers and get a few illegal copies than to clamp down so to have no illegal copies but inconvenient all our honest customers.

[BeeHay]

I found that if you use System.HideSystemMenu() right away, you will not be able to right click and select switch to development.

I would suggest using a delay() of something like 15 secs so you know you have 15 secs to open the document.

while(1)
	 delay(15)
	 System.HideSystemMenu()
endwhile

Found that out the hard way.

[AzeoTech]

A great idea. Or you can create a button somewhere in your document with password protection that if the proper password is entered reenables the system menu.

Also, why do you have hidesystemmenu() inside a loop?

[BeeHay]

Nice, a password protected page with "mod" like buttons to click sounds kinda neat.

About the hidesystemmenu(), I was just trying it out and in a loop with no delay before it was a bad idea.

[AzeoTech]

Yeah, infinite loops with delay() are typically bad unless you are running idle thread priority, and even then... Anyhow, you really only need to call it once so there is no need for the loop at all.