FiveTech Software tech support forums

Jose I have had trouble tabbing thru check-boxes and active gets in a mix of controls was confusing to users . I found this simple code which changes the color of the Get when it gets in focus: SetGetColorFocus( rgb(209,224,252) ...

Try adding this to ON INIT clause of the ACTIVATE DIALOG command:

Code: Select all  Expand view

oDlg:PostMsg( WM_KEYDOWN, VK_TAB )

Works fine here. I can see the square cursor when TABbing to a combobox.

EMG

... .. Probably just a 'disturbance in the force' :lol: Rick Lipkin ps .. still outstanding is the group issue with the Windows Manifest and xBrowse tabbing thru edit_listbox

... 1) Antonio, the new libs did not fix the BtnBmp error, however, the BtnBmp.prg replacement that Rao sent works great! :D 2) The xBrowse error when tabbing thru EDIT_LISTBOX still exists. I REALLY appreciate your quick response!! Rick Lipkin

... encountered odd behaviour with the dialogs I create. They worked perfectly in the "old environment" below. New Environment - problems tabbing forward and backwards, up/down arrow movement, colors on comboboxes. FWH 11.07 Harbour 3.0.0 (Rev. 16951) Borland C++ 5.82 for Win32 Turbo Incremental ...

... middle of the window, and the Tab is required to smootly go from the top to the bottom of the dialog). Right now, following the default behavior, tabbing make a first up-down pass focusing first all the .RC painted controls, and after that, another up-down pass focusing the controls I created ...

If understand correctly, the intention is that the Browse should never get focus, whatever the user does, including Tabbing, clicking on non-data area of the browse or using the scroll bar. The following code seems to work. PROCEDURE Main() ... oBrw:bChange ...

If understand correctly, the intention is that the Browse should never get focus, whatever the user does, including Tabbing, clicking on non-data area of the browse or using the scroll bar. The following code seems to work. PROCEDURE Main() LOCAL oDlg, oBrw, n := 1, oGet ...

... my efforts. What puzzled me was why the Return key works when you Back-Tab to that button. I'll go back and review with the users and see if tabbing through the gets/controls is acceptable to them and stick with Windows convention. Anotonio - Sorry that I haven't had a chance to produce a ...

... a BROWSE the user clicked on (normal click not double click - maybe this is already possible?) Solve issue with selection being reset when first tabbing into a BROWSE or LISTBOX This is becoming pretty important. Support multiple parameters to WinExec() function Would be very handy and hopefully ...

Firstly a big thank you to Antonio for his recent help changing default selection when tabbing through GETs. Combined with my workaround for controlling tab order it has made for some nice comments from my end users and made them more productive. Whilst I was controlling ...

... value it was set to in GotFocus() Conversely if you do click the title bar then ::GetPos() does return the expected value (0 if this is just after tabbing into the GET). I suspect that we may need to enhance the GotFocus() method of class TGet to include ::oGet:Pos := 0 to synchronise things. And ...

... the KeyDown() method the K_DEL case of the KeyDown() method the otherwise case of the KeyDown() method This significantly improves behaviour when tabbing into a GET. Now the cursor position on entering a GET via a tab is at the end of the non-blank text (which is OK). 2. Whilst the GotFocus() ...

... Replicate( "*", Len( AllTrim( ::oGet:buffer ) ) ) ) ) Hopefully this might stop us from tabbing to the end of a GET past where the meaningful text is. Regards Doug (xProgrammer)

Apart from first GET in a DIALOG cursor seems to go to the end of the contents when tabbing into a GET. Whereas it would be nice for it to go to the end of the non-blank text and / or the start. This is in part due to the way I have programmed - which may not be necessary. ...