New problem. I use ESC to exit from every form. I have a couple forms that only contain 1 edit table. When the user presses ESC, the edit table does not recognize the keypress. I've noticed that it is only edit tables that produce this (well not produce). Is there a way around this, because I would hate to have to tell the user that esc gets you out of every form except these forms, and when you get to these forms press something else. Thanks.

Clay

Are you using the CHAR event? If I put a msg call in the char event of a edit table it displays each time i press ESC. So it should work

[email protected]

DSigs Radio Free Oregon

Phone: 971-570-2005

OS: WinXP Pro

OI: 7.0

DSig,

Esc doesn't make it to CHAR in OI 4.2, but I'm glad to hear of this improvement in OI 7.0!

- Oystein -

huh? i did this on 4.1.3

I have a test window (not databound) and it has a couple of buttons and a table. In the char event script i put

call msg(@window,'Help .. im a rock')

and it worked.

After reading your post i tried it in a new window and it doesn't. hmmm will track it down and let you know

[email protected]

DSigs Radio Free Oregon

Phone: 971-570-2005

OS: WinXP Pro

OI: 7.0

DSig,

Sorry but I can't have Zappa lyrics in my app just to get it to work properly.

- Oystein -

First .. fz .. My guitar wants to kill your mama

Ok .. with that out of the way ..

make the table protected (more protected) and all of a sudden the esc works who would have thunk it ..

[email protected]

DSigs Radio Free Oregon

Phone: 971-570-2005

OS: WinXP Pro

OI: 7.0

So, unless they are not entering anything into the table, just wait for OI 7. Maybe that will be working sometime this year…..

Clay

I did some testing on this subject, and it is possible to capture the ESC key with a little finagling. First, a little background knowledge…

It's important to note that there is an invisible control between the Edit Table and the OI form. I verified this using a C++ spy utility. This "Middleman" control communicates between OI and the EditTable. Every time you call Get_Property or Set_Property on an edit table, the "MiddleMan" translates them into WinAPI calls to the actual edit table control.

Likewise, the EditTable control passes information to the Middleman, and the Middleman translates it into information useful to OI. Using the spy utility, I was able to confirm the following: when the user presses ESC, the EditTable never passes WM_CHAR or WM_KEYDOWN or any kind of notification to the Middleman control. In other words, the EditTable eats all ESC characters without ever letting the Middleman control know it happened.

Since the Middleman control is the translator and is never receiving information regarding the ESC key, OI will never know when the key is pressed. The only exception is when the whole table (not just columns) is protected. In this case, it appears that the EditTable chooses not to eat the ESC character and passes it to the Middleman. The Middleman, knowing there's a Cancel button, performs the correct operation.

Here's where I get to the goods. I discovered that by changing the key used to Abort edit mode in the edit table, the Middleman does receive WM_KEYUP messages. You can use this WinMsg to let the MiddleMan know that the ESC key was pressed.

Place the following code in your form's CREATE event handler:

Declare subroutine Send_Message, SendMessage



EQU WM_KEYUP$       to 0x0101

EQU DTM_SETEDITKEY$ to 0x045E



Send_Message(@WINDOW:'.EDT_TABLE', 'QUALIFY_EVENT', WM_KEYUP$, 1)



Handle=Get_Property(@Window:".EDT_TABLE", "HANDLE")

SendMessage(Handle, DTM_SETEDITKEY$, 3, 0)

The first Send_Message (with the underscore) tells OI to send WM_KEYUP events to the edit table's WINMSG event handler. The second SendMessage (without the underscore) is a WinAPI method used to send Win Messages directly to controls. The message I'm sending, DTM_SETEDITKEY$, allows you to alter the keys used to enter, exit, and abort edit mode in an edit table cell. In this case, I'm changing the abort key to 0 (NULL). This means there is no way to abort a cell while in edit mode using the keyboard. However, since you plan to close the form anyway, it shouldn't matter. But if you wish, you can set this to any other key on the keyboard. The result is that the edit table now sends WM_KEYUP WinMsgs to the Middleman.

Now add the following code to your edit table's WINMSG handler:

Declare subroutine PostMessage



EQU WM_KEYUP$ to 0x0101

EQU WM_CHAR$  to 0x0102



If Message EQ WM_KEYUP$ AND wParam EQ 27 then

    Handle=Get_Property(CtrlEntId, "HANDLE")

    PostMessage(Handle, WM_CHAR$, wParam, lParam)

end

This code simply responds to the KEYUP event by changing it into a WM_CHAR message and sending it back to itself. This way, the Middleman receives the notification and will execute the Cancel button if there is one.

[email protected]

SRP Computer Solutions, Inc.

Hi Kevin,

That worked really well. I wish I knew C enough to do what you are doing at your level. Thanks!

Clay

Kevin,

Neat! Works very well! Thanks from me too!

- Oystein -

Clay ..

]]So, unless they are not entering anything into the table, just wait for OI 7. Maybe that will be working sometime this year…..

Not sure where you got this. In one of my replies to Oy I SAID i was using 4.1.3.

The PROTECTED switch on the MORE page simply keeps the INSERT and DELETE key from working. I do not think it really serves any other function. You can enter data

Did you try it?

[email protected]

DSigs Radio Free Oregon

Phone: 971-570-2005

OS: WinXP Pro

OI: 7.0

Clay ..

]]So, unless they are not entering anything into the table, just wait for OI 7. Maybe that will be working sometime this year…..

Not sure where you got this. In one of my replies to Oy I SAID i was using 4.1.3.

The PROTECTED switch on the MORE page simply keeps the INSERT and DELETE key from working. I do not think it really serves any other function. You can enter data

Did you try it?

[email protected]

DSigs Radio Free Oregon

Phone: 971-570-2005

OS: WinXP Pro

OI: 7.0

Cool information man .. this kind of info would have been nice long ago

it is too bad that you have to be a c guru to use a basic program

[email protected]

DSigs Radio Free Oregon

Phone: 971-570-2005

OS: WinXP Pro

OI: 7.0

Kevin,

I have to wonder about one of the bits you mention ..

]]Likewise, the EditTable control passes information to the Middleman, and the Middleman translates it into information useful to OI. Using the spy utility, I was able to confirm the following: when the user presses ESC, the EditTable never passes WM_CHAR or WM_KEYDOWN or any kind of notification to the Middleman control. In other words, the EditTable eats all ESC characters without ever letting the Middleman control know it happened.

IF as you say here, the edit table eats all the esc characters, then why do I get the esc?

Well the obvious answer is that it passes the esc when the correct property is set AND that by using the 'protected' option on MORE must set a series of properties on the table .. disables insert disables delete BUT ENABLES esc.

cool stuff though .. thanks

[email protected]

DSigs Radio Free Oregon

Phone: 971-570-2005

OS: WinXP Pro

OI: 7.0

DSig,

IF as you say here, the edit table eats all the esc characters, then why do I get the esc?

Check your fridge. What happened to me once was my edit table sneaked out and snacked on some chicken rogan josh takeaway leftovers. After that it couldn't take another esc.

Clients don't go for this solution, though. Kevin's take is far superior.

- Oystein -

superior .. SUPERIOR .. he had to cheat. I used just what OI gives me . And since it works every time .. wahoo!!

And as for you chicken .. was it a proper chicken or some foreign thing with funny spelling

[email protected]

DSigs Radio Free Oregon

Phone: 971-570-2005

OS: WinXP Pro

OI: 7.0

DSig,

was it a proper chicken

How should I know? I just copied the name off the web.

- Oystein -

DSig,

…he had to cheat. I used just what OI gives me .

Understanding that this is all in jest, I would contest the claim that he cheated. The final solution that Kevin offered IS what OI gives you. That is to say, everything can be done within the toolset that OI gives you as opposed to another solution that, for instance, would have required a DLL to be written.

There was nothing unique in the code that Kevin provided. That is to say, if you include the Programmer's Reference Guide and this website you'll find other examples that call the same essential functions (i.e. SendMessage and PostMessage). The only difference in this situation was that Kevin had to dig a little to figure out how it all works together.

Once upon a time it was deep magic to figure out how to change the edit toggle key from F2 to something else. By now I think it is considered common knowledge. This too shall pass…

[email protected]

SRP Computer Solutions, Inc.

View this thread on the Works forum...