MC_menu problem

John Martens

unread,

Dec 21, 2006, 2:36:42 AM12/21/06

to

In a VO menu I have as accelerator PGUP this workded fine with the MED code.

Now the line
SELF:AddItem(#DlnVorige,"Vorige"+MC_C_TAB+"PGUP","Vorige
persoon",KEYPAGEUP,FALSE,FALSE,FALSE)

will cause a 5333 while other KEYxx values like KEYF4 work fine.

What other value for PAGEUP and PAGEDOWN do I have to use ??

John

Saulo Rodrigues

unread,

Dec 21, 2006, 7:18:14 AM12/21/06

to

Hi John

I did a test using KeyPageUp and KeyPageDown and it works with no
problem here.

hth
Saulo

John Martens

unread,

Dec 21, 2006, 12:50:22 PM12/21/06

to

Saulo,

So no compile and no runtime problem ?

My problem arises from the line:
SELF:ActivateAcceleratorKeys(oOwner)
I suppose you call this one too

If I comment the PgUp line out the problem is gone.

John

Saulo Rodrigues schreef:

Saulo Rodrigues

unread,

Dec 21, 2006, 1:20:08 PM12/21/06

to

Hi John

> So no compile and no runtime problem ?
> My problem arises from the line:
> SELF:ActivateAcceleratorKeys(oOwner)
> I suppose you call this one too

Yes, I do. Anyway, have you tried it with another keys eg. KEYARROWUP?
Saulo

John Martens

unread,

Dec 21, 2006, 2:47:23 PM12/21/06

to

Saulo,

Same problem with KEYARROWUP.
No problem with KEYF4 etc.

Are you on VO 2.7 ?
With 2.6 I never had 5333's and 2.7 seems to be more critical with it.

John

Saulo Rodrigues schreef:

Saulo Rodrigues

unread,

Dec 21, 2006, 3:19:44 PM12/21/06

to

John,

> Same problem with KEYARROWUP.
> No problem with KEYF4 etc.
> Are you on VO 2.7 ?
> With 2.6 I never had 5333's and 2.7 seems to be more critical with it.

VO2.7 (2740)
Are you using an inherited class? If so, try using the original class
instead to see if the problem persists.

Regards
Saulo

Marc Verkade [Marti IT]

unread,

Dec 22, 2006, 5:26:35 AM12/22/06

to

Here is my KeyUp method. I do not use accelerators for that.

METHOD KeyUp(oKeyEvent) CLASS MC_SelectDataDialog

LOCAL DIM aKeyStates[256] AS BYTE

LOCAL oObject AS OBJECT

DO CASE

CASE oKeyEvent:KeyCode==KEYINSERT .AND.
LOGIC(_CAST,_And(GetKeyState(VK_CONTROL),SHORT(_CAST,0x8000)))

SELF:Append()

GetKeyboardState(@aKeyStates)

IF _And(aKeyStates[VK_INSERT+1],1)==0

aKeyStates[VK_INSERT+1]:=1

SetKeyboardState(@aKeyStates)

ELSEIF _And(aKeyStates[VK_INSERT+1],1)==1

aKeyStates[VK_INSERT+1]:=0

SetKeyboardState(@aKeyStates)

ENDIF

CASE oKeyEvent:KeyCode==KEYDELETE .AND.
LOGIC(_CAST,_And(GetKeyState(VK_CONTROL),SHORT(_CAST,0x8000)))

SELF:Delete()

CASE oKeyEvent:KeyCode==KEYARROWUP

IF !Empty(SELF:Server)

SELF:Server:Skip(-1)

IF SELF:Server:Bof

SELF:Server:GoTop()

END

CASE oKeyEvent:KeyCode==KEYARROWDOWN

IF !Empty(SELF:Server)

SELF:Server:Skip(1)

IF SELF:Server:Eof

SELF:Server:GoBottom()

END

CASE oKeyEvent:KeyCode==KEYPAGEUP

IF !Empty(SELF:Server)

SELF:SkipMultPrevious()

END

CASE oKeyEvent:KeyCode==KEYPAGEDOWN

IF !Empty(SELF:Server)

SELF:SkipMultNext()

END

CASE oKeyEvent:KeyCode==KEYHOME .AND.
LOGIC(_CAST,_And(GetKeyState(VK_CONTROL),SHORT(_CAST,0x8000)))

IF !Empty(SELF:Server)

SELF:Server:GoTop()

END

CASE oKeyEvent:KeyCode==KEYEND .AND.
LOGIC(_CAST,_And(GetKeyState(VK_CONTROL),SHORT(_CAST,0x8000)))

IF !Empty(SELF:Server)

SELF:Server:GoBottom()

END

CASE oKeyEvent:KeyCode==KEYF5

oObject:=GetFocusedObject()

IF oObject:NameSym==#FILTERSLE

SELF:SetFilterText()

RETURN 1L

END

RETURN SUPER:KeyUp(oKeyEvent)

"John Martens" <CA...@TennisHulp.info> schreef in bericht
news:458a3982$0$750$5fc...@dreader2.news.tiscali.nl...

John Martens

unread,

Dec 22, 2006, 7:14:58 AM12/22/06

to

Marc,

I finaly found the problem. It was a coincident that the problem was in
PGUP. The real problem is this:

CLASS MC_AcceleratorKeys INHERIT vObject
HIDDEN DIM structAccelerator[24] IS _WINACCEL
HIDDEN nCount AS INT
HIDDEN hAccelerator AS PTR

Ading a 25th accelerator will give a normal error and direct after a 5333.

Simply changing 24 into 29 doesn't work.

What kind of limit is this ?

John

Marc Verkade [Marti IT] schreef:

Marc Verkade [Marti IT]

unread,

Dec 22, 2006, 8:10:26 AM12/22/06

to

Aha....
That's just a figure I used.. No limit.
Mine is :
CLASS MC_AcceleratorKeys INHERIT vObject

HIDDEN DIM lpAccel[100] IS _WINACCEL

HIDDEN nCount AS INT

HIDDEN hAccel AS PTR

"John Martens" <CA...@TennisHulp.info> schreef in bericht

news:458bcc41$0$747$5fc...@dreader2.news.tiscali.nl...

John Martens

unread,

Dec 22, 2006, 10:55:39 AM12/22/06

to

Marc,

I changed it in
CLASS MC_AcceleratorKeys INHERIT vObject
and then I still got an error, changing in

ACCESS GetAcceleratorHandle() CLASS MC_AcceleratorKeys

Did the job.

Now another problem: I started to convert to MC_menu because I saw that
Memory(MEMORY_REGISTERAXIT) went up and up when using another Menu class
that finaly gave me a 5333.

Now the 5333 is gone but I expected to get a stable number of
Memory(MEMORY_REGISTERAXIT) before opening a window and after closing it
and calling CollectForced().

When I do not assign a MC_menu to a window this is the case. The number
goes from lats say 80 upto 150 and down again to 80 when closing the
window and do a CollectForced().

When I assign MC_menu to a windo it goes from 80 upto 160 and only back
to 120, opening the window again it gets up to 200 and soforth.

Do you know what causes this and how can I avoid it ?

Marc Verkade [Marti IT]

unread,

Dec 24, 2006, 10:41:54 AM12/24/06

to

Hai,
Here are our menu-classes.
I can remember that we had find dimu lar things going on, but really can not
recall.
I saw some modifications in the destroy mtehod of the menu....

Here are our own classes, from Our lib so they will not compile.
www.marti.nl/mefs.zip

You can use them to compare if things are different in our production
classes.

Grtz, Marc

"John Martens" <CA...@TennisHulp.info> schreef in bericht

news:458bfffb$0$721$5fc...@dreader2.news.tiscali.nl...

John Martens

unread,

Dec 24, 2006, 11:20:22 AM12/24/06

to

Marc,

Now MC_menu became as subclass of SEmenuXP so t it hard to see what
happens and whats in the SEmenu code (that I do not have).

The problem might be in the Destroy() methods. MC_menu that I downloaded
from your website does not have one.

The help file say's on Menu:Destroy()
Purpose
Provide a method to de-instantiate a Menu object.

Syntax
<oMenu>:Destroy() ---> NIL

Description
This method can be used when a Menu object is no longer needed.
Menu:Destroy() de-instantiates the Menu object and allows you to close
and free any resources that were opened or created by the object,
without waiting for the garbage collector.

Do I have to call a Destroy in the close of a window ?

Reading Geoffs 5333 paper I would say NO becuase the GC will get them
but by not doing anything after closing a window
Memory(MEMORY_REGISTERAXIT) wil go up and up so there are things in
memeory that are not removed by the CG.

John Martens

unread,

Dec 24, 2006, 11:35:51 AM12/24/06

to

Marc,

Experimenting with Destroy() did the job.

I need to call SELF:Menu:Destroy() in the Close of a window in order to
get the menu out of the memory.

Memory(MEMORY_REGISTERAXIT) is now stable before opening a window and
afterwards.

John

Marc Verkade [Marti IT] schreef:

Marc Verkade (prive)

unread,

Dec 24, 2006, 2:06:55 PM12/24/06

to

I thought so..
Can you post your Destroy method so I can add it to the sample?
Grtz, Marc

"John Martens" <CA...@TennisHulp.info> schreef in bericht

news:458eac65$0$732$5fc...@dreader2.news.tiscali.nl...

Marc Verkade (prive)

unread,

Dec 24, 2006, 2:08:44 PM12/24/06

to

Yes, but that has nothing to do with that...
I asked Adriano to implement de SEMenu classes withiun our MC_Menu classes
for the looks.
Furthermore I saw the Bold-thing from Amilcar. Do with it what you want.I am
glad it works correct now.

Grtz, Marc

"John Martens" <CA...@TennisHulp.info> schreef in bericht

news:458ea8c4$0$712$5fc...@dreader2.news.tiscali.nl...

John Martens

unread,

Dec 24, 2006, 4:06:37 PM12/24/06

to

Marc,

There was no need to build a special MC_menu:Destroy(). The normal
Menu:Destroy() seems to do the job.

John

Marc Verkade (prive) schreef: