INKEY Function Slow

[bpjabjr]

When changing from Dell 755 to 960, the INKEY function doesn't work properly.

For example: I wrote a little program that writes the date and time to a file after waiting first one second, then five seconds and then ten seconds. This should take sixteen seconds to run. On the Dell 755, it takes sixteen seconds. But on the Dell 960 it takes about thirty five seconds. Also, the file that is created outputs the times correctly.

HELP!!!

 

[TonHu]

Show what you got so far, your current display is quite mudded

 

[bpjabjr]

SAY_MSG("BEF WAIT 1 SECOND")
INKEY(1)
SAY_MSG("AFT WAIT 1 SECOND")
INKEY(5)
SAY_MSG("AFT WAIT 5 SECONDS")
INKEY(10)
SAY_MSG("AFT WAIT 10 SECODNS")

The SAY_MSG function writes a line to a text file. The text file contains:
BEF WAIT 1 SECOND 3:13:40
AFT WAIT 1 SECOND 3:13:41
AFT WAIT 5 SECONDS 3:13:46
AFT WAIT 1 SECONDS 3:13:56

The program takes 30-35 seconds to execute.

 

[bpjabjr]

Sorry about the typos. I have the program and output on another PC.

 

[GriffMG]

I know INKEY isn't really intended for this kind of thing... and bearing in mind that you are running a DOS application on what is, almost certainly, a Windows PC I would not expect it to be very accurate.

You might be better off using a different method of 'waiting' for a timed delay.

One approach (for small timings like this) would be to use the seconds() function:

? "hello"
? seconds()
i = seconds()
do while i > seconds()-10
  inkey()
enddo
? seconds()

BTW Is anything else running on the new machine?
Which versions of the OS are on the respective machines?
Do they have the same antivirus etc?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[bpjabjr]

The two machines run the same virus software and are Windows XP SP3. Nothing else is running.

I tried the SECONDS() function like suggested and it had the same result as the INKEY on the 960. It took 35 seconds to run.

We have now found other Dell 960s that run the test program with success.

We thought that we had found that the version of the BIOS was the difference. The BIOS version on the 960 that worked was A01 and on the one that didn't was A03. We changed the BIOS to A03 on the one that worked and it still worked.

I did find that the TONE function does work. I was hoping to find a solution where I didn't need to change all 275+ programs, but I have now been given the word to go with the TONE command and create a new function that functions like INKEY and change all of the programs to add the TRANSLATE command that will change all instances of INKEY to the new function.

Thanks for your help, I will continue to check for any other solution. I don't mind fixing the problem, I just would like to know what caused the problem to start with and what other functions may be involved.

 

[GriffMG]

Perhaps we are talking at crossed purposes...

Are you saying that the application takes 35 seconds to load, run and quit - but that the program itself does the steps you specify in the 15 seconds you require, and that you have evidence of that from the 'log file'?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[bpjabjr]

Yes. That is what happens.

 

[GriffMG]

In that case it IS NOT the inkey() function that is causing the problem - you do not need to rewrite it!

It could be a memory shortage, hence slow load/unload or some other machine specific problem (slow hard drive?)

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[bpjabjr]

What they did that caused this problem was upgrade the CPU from a Dell 755 to a 960. They used the same hard drive. Just moved it from one machine to the other.

We know that it is not the INKEY that is causing the problem. But in using the INKEY, the program is slower.

The free conventional memory is larger. But the free upper memory is a little lower 49600 for 755, 47632 for 960. The memory available for programs in the Del 960 is larger than the 755.

So, we don't feel that it is a memory or slow hard drive problem.

 

[TonHu]

Recompile using harbour-project.org or xharbour.org free xBase compilers and see what you get from a *real* 32 bit (or 64 bit with the right C-compiler) program. Running time is most likely slashed by some factor.
The bugs currently available from the Clipper 5.2 & 5.3 releases (even with all patches) are mostly squashed out as well.

Clipper is a 16 bit compiler, which was good enough when MS-DOS was 16-bit only, but in modern days you need modern tools. Clipper apps can not run on x64 Windows editions (the 16 bit subsystem is left out by Microsoft), a popular choice with Windows 7 and 4+ GB of RAM.

 

[bpjabjr]

I don't have the choice to change to a new compiler or a new language right now. We are converting all of the old clipper apps to VB.NET sometime in my lifetime, but I have to get the new Dell 960s up and running now.

I appreciate everyone's help, but I have to change the INEKY and SECONDS functions to use WAITPERIOD and TIMETOSEC. Passed down from the powers that be. They say that I have spent enough time on this and they need to get the PCs on the shop floor.

thanx again!

 

[GriffMG]

How 'Dilbert' is that - you've established it is not the Inkey() function that is causing the problem, so now that's what you are told to fix!

Good Luck!

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[bpjabjr]

How true. The stories that I could tell.

Again, thanks for all of your help. I will know where to turn next time. Most Clipper problems I can handle. This is hardware. I'm not much on hardware. It came down to the fact that we didn't want to have to test every new PC that we put out on the floor to see if it was slow. So we "put a bandage on it". (Most of you are probably too young to get that. It was from a computer game by Richard Scarry. The solution was always to "put a bandage on it". lol)

 

[r0gerc]

Is this something to do with delayed disk writing or have I completely missed the point here? I am still smiling about GriffMG's "Dilbert" comment!
Best of luck,
Roger

 

[GriffMG]

Thank you Roger!

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[bpjabjr]

r0gerc, I liked his Dilbert comment too. I also love his 10 kinds of people. I have to admit, I am not an instant binary person, but I did finally get it on my own.

I don't think that it is a delayed disk writing. It is a hardware issue that noone here at work seems to understand. We did find that time functions are not performing in a "timely" manner. So I am fixing the symptoms but not the problem itself.

 

[r0gerc]

But they are performing in a timely manner according to your text file. You can't improve on that can you?

Best wishes,
Roger

 

[bpjabjr]

What I found is that the TIME() function is related to the SECONDS() function, which doesn't work correctly either.

 

[GriffMG]

Is there a chance the program is 'looking for a resource' that was available to the version running on the old machine, that isn't fitted to the new one? Like, for example, a printer port?

I've not seen this with Clipper, but I have VFP apps that check the the printer defined in their settings files still exists and swaps to the Windows default if they don't - and the system is very slow to start up if the printer is missing.

Is there any start up code that could be 'held up' for some reason? Or close out code?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.