Virtual Listview and Keyboard.PBWin 7.02

[Tommy]

Hi,

Can someone tell me whether the Windows OS handles up/down keys in a
virtual listview (Report view) all by itself?

I have created such a control, but using these keys doesn't move the
cursor.I hope that is the right term.

I looked up the "Find.bas" in the sample directory and noticed that
there were no code there ment to handle these keys.At least I could
not spot it.But it works okay to navigate the control by these keys,
though.

In creation of my own LV I used the same parameters that is used in
the "Find.bas" file.

Anyone any clue by a chance?

Thanks!

--

[Tommy]

Hi,

The problem probably is caused by a memory override.But it is hard to
imagine so in the first place as long as there is no sign of such a
thing.

At top of my sourcefile I have placed a construct like this:

%DEBUG = 1
#IF %DEBUG
#DEBUG ERROR ON
#TOOLS ON
#ELSE
#DEBUG ERROR OFF
#TOOLS OFF
#ENDIF

With this construct my app has always compiled and run fine.But as
soon I changed that %DEBUG = 1 TO %DEBUG = 0 the app crashed just
after load.Most of the controls on it din't show up.Typical memory
corruption.

Isn't $DEBUG ERROR ON ment to catch errors in the code?It is rather
strange that #DEBUG ERROR ON hides errors instead of revealing them.

Well, now I have isolated all my subs and function, and navigating the
listview control works.

Hopefully I will find the spot for my memory override.

--

Post by Tommy
Hi,
Can someone tell me whether the Windows OS handles up/down keys in a
virtual listview (Report view) all by itself?
I have created such a control, but using these keys doesn't move the
cursor.I hope that is the right term.
I looked up the "Find.bas" in the sample directory and noticed that
there were no code there ment to handle these keys.At least I could
not spot it.But it works okay to navigate the control by these keys,
though.
In creation of my own LV I used the same parameters that is used in
the "Find.bas" file.
Anyone any clue by a chance?
Thanks!

[Michael Mattias]

Post by Tommy
%DEBUG = 1
#IF %DEBUG
#DEBUG ERROR ON
#TOOLS ON
#ELSE
#DEBUG ERROR OFF
#TOOLS OFF
#ENDIF
With this construct my app has always compiled and run fine.But as
soon I changed that %DEBUG = 1 TO %DEBUG = 0 the app crashed just
after load.Most of the controls on it din't show up.Typical memory
corruption.
Isn't $DEBUG ERROR ON ment to catch errors in the code?It is rather
strange that #DEBUG ERROR ON hides errors instead of revealing them.

Please RTFM.

With #DEBUG ERROR ON, on null pointer or array bounds violation the compiler
will set the ERR variable (error 9) and skip the statement.

Without the #DEBUG ERROR ON the compiler will just simply execute the
statement without checking...if you try to access memory not owned by your
application, Windows will handle the error (i.e., issue a general
protection fault).

That is, #DEBUG ERROR ON is useless for finding array bound/null pointer
errors unless you check ERR/ERRCLEAR or have an ON ERROR GOTO. trap set up.
(Or can live with statements being skipped without warning!).

Michael Mattias
Tal Systems, Inc.
Racine WI
***@talsystems.com