FocusRect Bug/Workaround

[clarkgriswald]

I am pretty sure this is a bug. I am using a CodeJock TaskPanel and have the DrawFocusRect property set to true. When I tab into the control and set the focused item, the focus rectangle is not displayed. If I start pressing the arrow keys to traverse the task panel items, the focus indicators start to show up. I am pretty sure this must be a bug in the control, so I am trying to find a workaround. I tried ensuring the correct focus queues were enabled before setting the focused item:

Call SendMessage(taskPanel.hWnd, WM_CHANGEUISTATE, MakeDWord(UIS_CLEAR, UISF_HIDEFOCUS), ByVal 0&)

But that seems to have no effect (likely due to the fact that my last operation was a TAB press, so the focus indicators should already be on. As expected, if I implemented a quick hack using send keys, the indicator is shown:

SendKeys "{DOWN}"
SendKeys "{UP}"

Clearly this is not ideal. Assuming I get no help from the control vendor (legacy product), does anyone have any other tips/tricks/workarounds that would be a bit more elegant/reliable than send keys hack?

[jpbro]

I just tried with a small test project using V19.3 and tabbing from a VB6 TextBox to the TaskPanel appears to work OK (the focus rectangle appeared in the TaskPanel). What version are you using? Can you post a minimal sample project the demonstrates the problem so I can test it here?

[clarkgriswald]

I just tried with a small test project using V19.3 and tabbing from a VB6 TextBox to the TaskPanel appears to work OK (the focus rectangle appeared in the TaskPanel). What version are you using? Can you post a minimal sample project the demonstrates the problem so I can test it here?

That may be the issue, since this is a legacy product, we are using version 12.0 - perhaps there was a fix implemented after v12? As for the sample project, let me try a small sample to ensure I see the same issue (although I suspect I will)

[jpbro]

I think I still have 12.x around in my backups, so if you can whip up a small reproducible sample project, I will see if I can find a workaround.

[clarkgriswald]

I just tried with a small test project using V19.3 and tabbing from a VB6 TextBox to the TaskPanel appears to work OK (the focus rectangle appeared in the TaskPanel). What version are you using? Can you post a minimal sample project the demonstrates the problem so I can test it here?

Ok, just created a small example and replicated the issue.

I had a form with 2 buttons and a TaskPanel (v12). The only code was the following:

Private Sub Form_Load()
    tskMain.Groups.Add 1, "Group 1"
    tskMain.Groups(1).Items.Add 2, "Link Section", xtpTaskItemTypeText
    tskMain.Groups(1).Items.Add "10", "Item One", xtpTaskItemTypeLink
    tskMain.Groups(1).Items.Add "11", "Item Two", xtpTaskItemTypeLink
    tskMain.Groups(1).Items.Add "12", "Item Three", xtpTaskItemTypeLink
    tskMain.Groups(1).Items.Add "13", "Item Four", xtpTaskItemTypeLink
End Sub

The first time I tab through the form, the Group has the focus rectangle drawn, but subsequent cycles do not draw the focus rectangles. Also added code to set FocusedItem when I click one of the buttons, but no focus rect drawn.

I basically want the focused item to have the rect drawn if the task pane receives the focus via keyboard (as well as setting the focused item manually to draw the rect)

Thanks for taking the time to try and find a workaround. In our task panel, we actually hide the group captions as well, but in my sample I left it visible to keep it simple.

[jpbro]

Your minimal example works OK in 19.3. I've just tried with 16.2.6 (which I had easier access to than 12.x) and I can reproduce the problem with that version, so it looks like the fix came somewhere in between. I'll see if I can find a workaround.

[jpbro]

Well I've only had a little luck. It appears that there's a bug in the TaskPanel which is preventing the FocusRect from drawing when the FocusedItem property is set (internally or externally). I've tried a bunch of things to force it to refresh, but nothing has worked so far.

The best option I've found so far is to set the FocusedItem property to Nothing in the GotFocus event:

Private Sub tskMain_GotFocus()
   Set Me.tskMain.FocusedItem = Nothing
End Sub

This will kill the focused item, and then a subsequent Tab press or Arrow key press will force the focus rectangle to be redrawn.

[clarkgriswald]

Your minimal example works OK in 19.3. I've just tried with 16.2.6 (which I had easier access to than 12.x) and I can reproduce the problem with that version, so it looks like the fix came somewhere in between. I'll see if I can find a workaround.

Good to know that I wasn't going crazy and that they at least addressed it (although we won't be updating for the legacy product).

Well I've only had a little luck. It appears that there's a bug in the TaskPanel which is preventing the FocusRect from drawing when the FocusedItem property is set (internally or externally). I've tried a bunch of things to force it to refresh, but nothing has worked so far.

The best option I've found so far is to set the FocusedItem property to Nothing in the GotFocus event:

Private Sub tskMain_GotFocus()
   Set Me.tskMain.FocusedItem = Nothing
End Sub

This will kill the focused item, and then a subsequent Tab press or Arrow key press will force the focus rectangle to be redrawn.

I have been playing with Got?LostFocus as well, so trying to nail down the best approach. Thanks for your time and ideas! If something else comes to mind, let me know!

[jpbro]

I found a a way that s along the same lines idea as your SendKeys approach, but using SendMessage instead. Not sure if there's any reason to prefer it, but I'll post it here in case.

Option Explicit

Private Declare Function SendMessage Lib "user32.dll" Alias "SendMessageA" (ByVal Hwnd As Long, ByVal Message As Long, ByVal WParam As Long, ByVal LParam As Long) As Long
Private Declare Function GetWindow Lib "user32.dll" (ByVal Hwnd As Long, ByVal Cmd As Long) As Long

Private Const GW_CHILD As Long = &H5
Private Const WM_KEYDOWN As Long = &H100
Private Const WM_KEYUP As Long = &H101
Private Const KEYUPFLAGS As Long = 65539  ' I cargo-culted this from StackOverflow - you might want to double check this magic number

Private m_InGotFocusEvent As Boolean   ' For ignoring "phony" item focus changes in the Got Focus event

Private Sub Form_Load()
   tskMain.Groups.Add 1, "Group 1"
   tskMain.Groups(1).Items.Add 2, "Link Section", xtpTaskItemTypeText
   tskMain.Groups(1).Items.Add "10", "Item One", xtpTaskItemTypeLink
   tskMain.Groups(1).Items.Add "11", "Item Two", xtpTaskItemTypeLink
   tskMain.Groups(1).Items.Add "12", "Item Three", xtpTaskItemTypeLink
   tskMain.Groups(1).Items.Add "13", "Item Four", xtpTaskItemTypeLink
End Sub

Private Sub tskMain_FocusedItemChanged()
   If m_InGotFocusEvent Then Exit Sub ' Ignore our "fake" item change
   
   ' This is a legit focus change, so do whatever you like here
End Sub

Private Sub tskMain_GotFocus()
   Dim l_ChildHwnd As Long

   m_InGotFocusEvent = True

   l_ChildHwnd = GetWindow(Me.tskMain.Hwnd, GW_CHILD) ' The trick is to send the message the the first child window of the TaskPanel - the main window doesn't process key presses
   SendMessage l_ChildHwnd, WM_KEYDOWN, vbKeyDown, 0&
   SendMessage l_ChildHwnd, WM_KEYUP, vbKeyDown, KEYUPFLAGS
   SendMessage l_ChildHwnd, WM_KEYDOWN, vbKeyUp, 0&
   SendMessage l_ChildHwnd, WM_KEYUP, vbKeyUp, KEYUPFLAGS
   
   m_InGotFocusEvent = False
End Sub

[clarkgriswald]

I will give that a try as well. Noticed another problem if the first item in the group is a control type and then there is one more group with a link item. Doesn't seem to focus the control natively and then if you tab out of the control, it would be great it it focused the next possible item in the panel. Kind of a weird set of circumstances as tabbing out of the control would leave the task panel naturally. But regardless, it doesn't seem like our tricks above will handle focusing the first item in the panel if it is a control. Thoughts? Also, trying to do this generically as to easily address these issues on multiple forms that share the same issue.

[ISAWHIM]

if you tab out of the control, it would be great it it focused the next possible item in the panel. Kind of a weird set of circumstances as tabbing out of the control would leave the task panel naturally.

For that, you need to intercept the keyboard input, BUT... It may still Tab-Out. As you notice, that is the "nature" of an OCX control. The window steals "TAB" events for itself, unless a control specifically intercepts it, internally.

When you want to create your own navigation rules... (Tab, Enter, Alt, etc...) You really have to set the forms "Key Preview" to True, than manage the individual key-strokes, where needed. This is not as effective within a control, directly. Windows has already claimed certain key-combos for itself, over any internal child-controls.

For instance, using "Select Case", to manage "Tab". Commonly done in the KeyUp and KeyPress events. (But you may need to intercept in KeyDown also, for tabbing.)

You check if you are in your control, and where you are in the control. If you are at the point where you want it to sub-navigate, instead of exiting, you force it to sub-navigate and then set the "KeyAscii" and/or "KeyCode" to 0, or vbNull. That tells windows that the "event" was managed, and it will not actually do the "Tab" action. (Usually this is an issue with "gaming", when using VB6. This is how it is normally manipulated for games.)

Some controls, like RichTextBox, give you an option to manage "Tab" as a "Control Tab Out" or as a "Self Tab Character". I forget the options name.

"Alt" is another hard one to manage, as it naturally is a shortcut to the "Menu Select".

Tab navigation may also have "other" keys to do what you want.

TAB = Tab-Next Object
SHIFT + TAB = Tab-Previous Object
CTRL + TAB = ??? Tab-Into Object level (Depends) {Also arrow or Ins, Del, End, Home, PgUp, PgDwn navigation}
CTRL + SHIFT + TAB = Tab-Up Object level (Depends) {Also arrow or Ins, Del, End, Home, PgUp, PgDwn navigation}
ALT + TAB = Switch "Program Windows"

[clarkgriswald]

Your minimal example works OK in 19.3. I've just tried with 16.2.6 (which I had easier access to than 12.x) and I can reproduce the problem with that version, so it looks like the fix came somewhere in between. I'll see if I can find a workaround.

Well I've only had a little luck. It appears that there's a bug in the TaskPanel which is preventing the FocusRect from drawing when the FocusedItem property is set (internally or externally). I've tried a bunch of things to force it to refresh, but nothing has worked so far.

The best option I've found so far is to set the FocusedItem property to Nothing in the GotFocus event:

Private Sub tskMain_GotFocus()
   Set Me.tskMain.FocusedItem = Nothing
End Sub

This will kill the focused item, and then a subsequent Tab press or Arrow key press will force the focus rectangle to be redrawn.

Just downloaded their latest version and I can still reproduce the focus issue. Setting the focus programmatically does not draw the focus rect for me.