1. Tracy Lamb
  2. PowerBuilder
  3. Wednesday, 3 August 2022 17:24 PM UTC

Hi all,

So my Beta Tester found something strange (and unacceptable) in one of my windows.  In the app, there are 4 windows each with a folder object. Each folder object is inherited from the pfc's u_tab object. This strange behavior is only happening in one of them.

When editing a dw in any of the tabs, clicking the keyboard TAB is taking them back to the tab page, not the next field.

The only thing I can think of is it's related to the key pressed?  I have some code in the KEY event on the folder object:

CHOOSE CASE key
	CASE KeyF1!
		this.SelectTab(1)
		idw_1.SetFocus()
	CASE keyF2!
		this.SelectTab(2)
		idw_2.SetFocus()
	CASE keyF3!
		this.SelectTab(3)
		idw_3.SetFocus()
	CASE keyF4!
		this.SelectTab(4)
		idw_4.SetFocus()
	CASE keyF5!
		this.SelectTab(5)
		idw_5.SetFocus()
	CASE keyF6!
		this.SelectTab(6)
		idw_6.SetFocus()
	CASE keyF7!
		this.SelectTab(7)
		idw_7.SetFocus()
	CASE keyF8!
		this.SelectTab(8)
		idw_8.SetFocus()
	CASE keyF9!
		this.SelectTab(9)
		idw_9.SetFocus()
	CASE ELSE
		return 0
END CHOOSE

return 0

I tried deleting that code from the tab object and putting it in each dw... user event ue_keypress tied to pbm_dwnkey. No luck.

Any thoughts would be appreciated. 

~~~Tracy

Accepted Answer
Tracy Lamb Accepted Answer Pending Moderation
  1. Thursday, 4 August 2022 02:36 AM UTC
  2. PowerBuilder
  3. # Permalink

OK... I figured it out...

For some reason, I had a Return 1 in the code for that dw in the ue_keypress event (which is tied to pbm_dwnkey)... changed that to Return 0 and everything works as expected.  Although the Help file says return 1 only applies to RichTextEdit control, which I don't have in my dw.

Thank all for your feedback. I sincerely appreciate it.

~~~Tracy

Comment
  1. John Fauss
  2. Thursday, 4 August 2022 04:13 AM UTC
Glad you found the cause, Tracy!

For Windows-type (i.e., not unique to PB) events, such as this one, a Return 1 indicates to Windows that the object/control did NOT elect to process the event, so Windows dutifully propagated the event up the parent object hierarchy, until the tab control received and processed it.
  1. Helpful 1
There are no comments made yet.
Olan Knight Accepted Answer Pending Moderation
  1. Wednesday, 3 August 2022 20:41 PM UTC
  2. PowerBuilder
  3. # 1

Open up the errant DW in the DW Painter, then look at the DW Object.
Enable the TabOrder viewer on the DW Painter.
Now ensure that your columns are set up to flow in a meaningful manner.

Comment
  1. Tracy Lamb
  2. Thursday, 4 August 2022 01:16 AM UTC
Tab order is all fine.
  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Wednesday, 3 August 2022 20:23 PM UTC
  2. PowerBuilder
  3. # 2

Hi,

In addition to what John says, have a look at your tabsequences of the columns and protected attributes.

See if there's something weird in the ItemFocusChanged() events.

regards,

Comment
There are no comments made yet.
John Fauss Accepted Answer Pending Moderation
  1. Wednesday, 3 August 2022 19:35 PM UTC
  2. PowerBuilder
  3. # 3

Hi, Tracy -

If the errant behavior occurs when input focus is in the DataWindow, then I would look at events in the DataWindow control, such as a custom event mapped to event code pbm_dwnkey. The control that has input focus will have the first opportunity to process a keyboard event. If it does not do so, Windows will then propagate the event up the parent object hierarchy until it gets processed, either explicitly by code you've written or by the object's DefWindowProc (default window procedure).

Good luck!

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.