Help with DateTimePicker OCX Control

[O11Y]

Hi,

I've implemented a DTPicker Control (MSCOMCT2.OCX) into a form and it appears to be functioning correctly except for one thing. When I try to tab out of the control the tab position loops back to the first (in my case "day") field and leads to an inescapable loop where you can no longer tab from the control to the other form components.

I've tried implementing a counter for tab / shift-tab presses (in event KeyDown ) and then manually forcing focus into the next component but the OCX control is oblivious to this counter so when I tab out backwards and tab back in I'm transported to the last field because the OCX tabbing has wrapped around. Also any mouse clicking puts the counter out of sync and leads to furthur ""crazy" behaviour. I tried using return no-apply in the trigger to put me one step closer to predictable behaviour but this did nothing at all, perhaps because the DTPicker uses it's own inbuilt tabbing and is not event driven.

My only other idea was to use the callbackKeyDown event and create 2 empty callback fields at either end of the control. This was meeting with some success except that callbackKeyDown doesn't seem to respond to the tab key.

has anyone had any experience with this control or have any ideas?

Thanks.

Olly

 

[Lee Curzon]

It took me a while to replicate your error, and I wondered what your versions were (I'm on 9.1D07, DTPicker 6 SP 6).

Anyway, here's a guess: The HonorProKeys property is set to False.

Set it to true and try again.

Other than that, I'm stumped.

 

[Lee Curzon]

(HonorProKeys determines whether or not Progress handles certain keys, or leaves it to OCX).

From the ghastly online docs:

----

HonorProKeys property

Determines who processes the GO, ENDKEY, HELP, and TAB keys: Progress, or the ActiveX control to which the property applies.


Data type: LOGICAL Access: Readable/Writeable Applies to: Any ActiveX control

If the property is TRUE, which is the default, Progress intercepts these keys and processes them as normal Progress key events. If the property is FALSE, the keystrokes are sent to the ActiveX control for processing.


Note: This property resembles the HonorReturnKey property, which governs processing of the RETURN key, but whereas the default setting for HonorProKeys is TRUE (Progress gets the event), the default setting for HonorReturnKey is FALSE (the ActiveX control gets the event).

----

 

[O11Y]

Hi Lee, thanks for the help but alas my honorprokeys attribute was already set to true. I think i've reached the end of my tether and am going to knock something together in progress instead of using the OCX.

cheers,

Olly

 

[Lee Curzon]

Sorry it didn't help. If you work out the problem, let us know your solution.

 

[Lee Curzon]

Hey, We're back up!


I am assuming you are on at least version 9, so the fact that your HonorProKeys isn't working is odd. It may be a configuration/installation issue.
It is useful if you can post all relevant version information (OS, Progress, OCX, etc.) when you have a problem, as this is often relevant.

Anyway here's a couple of other ideas (try the last one first):

1. Reinstall your OCX - I won’t suggest reinstalling Progress/Windows for this minor situation .

2. Create a skeleton program - 2 fill-ins, one to either side of OCX (with default properties), and step-by-step alter the properties and tab order.
If tabbing is not intercepted with this initial skeleton configuration (and HonorProKeys set to TRUE), it does suggest a configuration/installation problem.

3. Here's a code change that may work. Try it with both HonorProKeys settings. Note that even if it does work for you there is still an annoying (minor) glitch you may notice - I can have a look at that when I'm back at work. I haven't tested it comprehensively, but it works on mine:



Adjustment 1 ----

[Global variables]


/* Local Variable Definitions --- */

DEF VAR lOCXFirstTimeIn AS LOGICAL NO-UNDO.

----


Agjustment 2 ----


&Scoped-define SELF-NAME CtrlFrame
ON ENTRY OF CtrlFrame /* DTPicker */
DO:

lOCXFirstTimeIn = TRUE.

END.


----



Adjustment 3 ----

PROCEDURE CtrlFrame.DTPicker.KeyDown .
/*------------------------------------------------------------------------------
Purpose:
Parameters: Required for OCX.
KeyCode
Shift
Notes: Tab captured because Progress is not intercepting it
even though HonorProKeys is set to True.
------------------------------------------------------------------------------*/

DEFINE INPUT-OUTPUT PARAMETER p-KeyCode AS INTEGER NO-UNDO.
DEFINE INPUT PARAMETER p-Shift AS INTEGER NO-UNDO.


IF p-keycode = 9 AND lOCXFirstTimeIn THEN /* Tab pressed */
DO:

lOCXFirstTimeIn = FALSE.
IF p-shift = 1 THEN /* Shift pressed */
APPLY 'entry' TO fill-in-1 IN FRAME default-frame.
ELSE
APPLY 'entry' TO fill-in-2 IN FRAME default-frame.

END.



END PROCEDURE.


----

HTH

Lee


ps. sorry for crappy indentation - It's pasted from WordPad

 

[Lee Curzon]

"I've tried implementing a counter for tab / shift-tab presses (in event KeyDown ) and then manually forcing focus into the next component but the OCX control is oblivious to this counter so when I tab out backwards and tab back in I'm transported to the last field because the OCX tabbing has wrapped around."

Oops - just reread this bit. You may have already tried option 3, I'm not sure.

Like I said - the code works on my PC, but when tabbing into the OCX, it lands on the next date segment from previous tabbing - which is annoying, and this may be what you mean by above.

(Incidentally, is the HonorProKeys property working correctly with other OCXs?)

 

[O11Y]

Hi Lee,

Thanks very much! I have at present abandoned the DTPicker control and cobbled together my own using a fill-in widget, button widget, and an overlaying window containing a month view control with the title bar & borders removed. However this problem may indeed reoccur in other OCX components so it would be good to sort it out and avoid problems in the future. I will have another go and get back to you.

thanks again,

Olly