FiveTech Support Forums

Hi Antonio

I am still trying to fix the operation of GET objects. I want to be able to use blocked text.

I believe that the ::SetPos() and ::SetSel() methods of class TGet actually work (certainly ::GetPos() works), but that some subsequent code (in GTK+ ?) is undoing their effect.

I know that changing ::SetPos() to always set the position to 0 has a dramatic effect on data entry. So it must be functional, at least at the time that the KeyDown() method is called.

I have played around a bit more and discovered that if you click on the title bar of the dialog then the correct effect is obtained. So maybe some form of refresh/update is required.

Can you help throw light on this?

Thanks
Doug
(xProgrammer)

Doug,

Please provide me a small PRG example to test and lets synchronize our source code so we use the same code for testing

Hi Antonio

If we can find out the event that fires when you click on the title bar of a DIALOG in FiveLinux I think we can solve this.

Trouble is I don't know how to fond that out.

Regards
Doug
(xProgrammer)

Hi Antonio

Simple source for test program follows. It is testdlg.prg with two minor changes, namely cAddress is initialised with some non blank data and secondly the PASSWORD option has been removed from the associated get.



Now if you compile and run this program you will find that if you tab from the first GET to the second the following will happen:

1. focus will change to the second GET
2. the whole of the text of the second GET is marked as having been selected
3. the keyboard cursor is at the very end of the get and you can't enter any text unless you backspace or use your mouse etc.
4. if you click on the title bar of the dialog then the selection marking disappears and the cursor moves to the start of the GET (which is the effect your code appears to be trying to achieve and would be ideal).
5. If you tab forward through to that GET again you can see that although the whole GET is marked as selected it doesn't behave as selected. Hitting a key leaves the cursor at the end of the GET but clears the selection marking.
6. If you tab from the second GET through to the third GET and then hit shift-tab you will see that it takes you to the start of the third GET but not back to the second GET as I believe it should. (I think this requires an additional case in the KeyDown() method of the TGet class.

I will send some more info in a further post

Thanks for your help

Doug
(xProgrammer)

Hi Antonio

As I indicated in another post a partial solution was to RTrim(::oGet:buffer) before using it to SetText. This doesn't fix the basic problem but does mean that the cursor goes to the end of the non-blank text.

What I have done subsequently is to try to fix get.prg and gets.c. I have shown that

::GetPos() will return positions - but they seem to be lengths - ie reflecting cursor position is at the end.

The GotFocus() method of class TGet is being called on the GotFocus event.

That after ::SetPos( 0 ), ::GetPos() will return 0 (if called still within the GotFocus() method

The screen display does not reflect the setting of the cursor to position 0, nor does it reflect ::SetSel( 0, 0 )

That if you click on the title bar the screen display reflects both ::SetPos( 0 ) and SetSel( 0, 0 )

If you don't click the title bar then the value returned by ::GetPos() in the KeyDown() method of Tget class reflects the cursor being at the end of the GET - and not the 0 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 I would like to support Shift-Tab

It would be highly desirable to support selections - but we will need to have a GETGETSEL method (and get two values returned)

Regards
Doug
(xProgrammer)

Doug,

You have emailed me TButton instead of TGet

Hi Antonio

I have emailed you my get.prg and gets.c - but they have been modified with a view to finding out what is happening rather than being solutions to the GET problems.

I think that the first step is for you to compile and link the little test program (slightly modified testdlg.prg) that I posted and verify that you are getting the same set of behaviours that I get. Then see if you think that whats happening internally is in line with my thoughts.

I do have an idea I will be pursuing today.

Thanks

Doug

Hi Antonio

No real progress on this issue. Clicking on the title bar will bring the cursor position to 0 and remove any selection regardless. Simulating that in code (I can't work out how) might give some sort of solution.

In the GotFocus event of the GET I can set the position to zero and confirm with ::GetPos() but you don't see it and then when you enter KeyDown GetPos() returns the original (end of string) value.

This isn't how other GTK+ applications behave. Something must be resetting it. But what?

Solving this may well give us the information we need to solve the BROSE index resetting problem - I am beginning to think that they are the same basic problem.

Regards

Doug

Doug,

We are going to do some tests here.

We already tried it but lets see if this time we have more luck

Hi Antonio

BROSE in last post should read BROWSE.

At this stage my best guess (could well be wrong) is that whatever is happening, it looks like it has to be in WinRun() because ::GetPos() reports 0 in GotFocus event but by KeyDown event its value has reverted.

Couldn't see the source for WinRun()

Regards
Doug
(xProgrammer)

Doug,

WinRun() or WinExec() ?

Hi Antonio

Whatever code is running between the GotFocus event and the KeyDown event.

We seem to be able to ::SetPos() because ::GetPos() returns the set position. I confirmed this by changing GotFocus to ::SetPos( 1 ) and ::GetPos() then returned 1. I also changed to ::SetSel( 1, 2 ) and after that ::GetPos() returns 2. So that all seems to be working. Plus in doing all that I verified that clicking on the title bar indeed works because lo and behold if I did that I got just the second character of the GET text highlighted. Putting in a MsgInfo() has the same effect. That may suggests that there is some event required to fire to get what we want?

However following on from that I observed that if you keep clicking on the title bar what happens is:

the first time ::GetPos() reports the end of the GET text before resetting, thereafter it only goes to 2 (the effect of the ::SetSel() - interesting because it has a degree of similarity with the BROWSE issue.

Anyhow given that ::GetPos() does seem to be working and its return value changes between the two events we should be able to chase down where it is being altered with suitable inserts into the code. I assumed that the xHarbour code that was running between the two events was WinRun() as called from TDialog. But you would know better than me.

Regards
Doug
xProgrammer

Hi Antonio

A few more observations

If you put a pause in GotFocus() method you discover that

1. first GET has GotFocus event before all the labels (SAYs) have been painted.

2. that there is no selection showing on the text of the GET after the GotFocus() method runs - it happens later

3. This is true even after a self:Refresh()

Regards
Doug
(xProgrammer)

Doug,

We are doing lots of tests and we can't remove the entire selection of the GET

Please let me know when you are online so we may try to have a live session with skype and logmein

Hi Antonio

Sounds great - but first I will have to drag myself out of the dinosaur age and install Skype and Logmein - I guess I need to resuscitate a Windows box? May take a day or two. I would love to solve this (and lets get more people using fivelinux)

Regards
Doug