I have a strange situation:

I have a search session, in which the user enters a range of search words in the top part of the screen. After tabbing a field the query is performed again (rebuild.query and first.set), and the results are shown in the bottom part of the form, multi occurance.

When using the tab to move between fields, everything works fine. When using the <arrow down> key, then - after once or twice - the system hangs!! I debugged, and saw that the program sequence is followed the same way as when tabbing, and the system simply hangs when it tries to execute first.set...

Anyone an idea of what causes this, and how to resolve/overrule this problem? Can I trace/fetch the arrow down action in my program script? Then I could maybe bypass the issue by forcing a tab instead or so.....

One more thing:
when looking at the ticks while the system 'hangs', it runs approx. 10.000.000 ticks per second (10 million)!!!

One more remark: when I trace the predefined variable 'choice', it doesn't switch to a different choice when using the arrow down key. So not even a different choice is being used. I tried replacing execute(first.set) with execute(first.view), but then also the problem occurs.

Anybody an idea?

I am not sure you can trap the arrow key without writing a whole bunch of code. There is a post in here somewhere that shows how to do that. The way I solved this in one session is that I made the user click a button - then I ran a routine to make sure everything I needed was set. For some reason no matter how many times we stress using the "tab" key the user conveniently forgets. In this case the button calls the same routines that the "tab" does.

Some time ago I also had that kind of problem. I decided to add logging code to each 4gl event (e.g first.set/before.choice: lprintf("first.set/before.choice")) and so on.

lprintf() is a pretty old function of my own that does three things: open a text file in append mode, write to it, close it. The system overhead is not too much, but I can use a simple 'tail -f ...' to look online into baan ...

Maybe that could help you to find out what goes wrong?

Günther

Günter, thanks for your reply. Do you also remember if you found the problem or a resolution for the problem? Also, if already you mention it, can you please post me the source of your lprintf function? Just to satisfy my laziness...

Thanks!!

I was a bit lazy, too. So I cannot find the solution of my problem. Sorry.

But here is the requested code:


|*********************************************************
|* functions for logging / debugging
|*********************************************************
#pragma nowarnings
#pragma nodebug

string local.fname(255)
long local.fd

function lopen(string fname(255))
{
local.fname = fname
return
}

function lprintf(string fmt(1024), ...)
{
long rc
string buf(1024)

buf = vsprintf$(fmt, ...)

local.fd = seq.open(local.fname, "a") | 1. open()
if local.fd < 0 then
return
endif

rc = seq.puts(buf, local.fd) | 2. write()
rc = seq.close(local.fd) | 3. close()
| => use tail -f on UNIX machines
return
}

function lclose()
{
return
}