FiveTech Support Forums

Hi Antonio

Another observation - it doesn't happen with the first GET on a screen when it first comes up, nor does it happen when you click into a GET, only when you Tab into it.

Doug

Doug,

It seems that GTK standard behavior is to select all the GET text when arriving to it using Tab. We have tested it with other GTK+ apps, same behavior.

We are asking about it in irc.gnome.org channel #gtk+ to see if there is a way to change it

Hi Antonio

I hadn't noticed before, but yes that does look like the default. However we are modifying that in the GotFocus() event. That appears to be happening after any default is applied. I say that for two reasons:

1. If you click on the title bar the correct highlighting is shown. So what we have set is still in place at this stage even though it is not reflected on the screen.

2. If that is the cause we can see from inserted calls to ::GetPos() that the select all effect has already taken place when we enter GotFocus() method.

That very much suggests to me that we need to enforce a repaint of the GET at the end of GotFocus() method. I have tried a variety of approaches in the past without success but I do note that self:Refresh() was doomed to failure as it just resets the text. Perhaps we need to call a GTK function such as:



Just one other thing. I('m not sure how our callbacks post their return values, but it looks like we are returning nil? Is that so? Maybe we need to be specific about whether we want further processing and return TRUE or FALSE ?

Regards
Doug

Doug,

Finally! This seems to be what we are looking for:

"gtk-entry-select-on-focus"

It seems as a global setting. Now we need to know how to set that property to false.

We can create a file at home/user folder named

.gtkrc-2.0

and inside have:

gtk-entry-select-on-focus = 0

We may also find how to do it programmatically, probably using gtk_settings_set_property_value()

Anyhow the selected text is gone but there is no blinking cursor! :-S

Doug,

Its working fine! As desired!

This code is the right one:

Now we just need to programmatically set that property, without the need of the external file, and we are done

Hi Antonio

Sounds very promising.

This might be the call:

Doug,

I got help from the IRC channel and we have it

No need for the external file. Simply include this line at the bottom of gets.c CREATEGET():

gtk_rc_parse_string( "gtk-entry-select-on-focus = 0" );

its working here! Please check it there

Hi Antonio

That's wonderful news - and thanks for your effort. Will try it out the moment I get back to my development pc today.

Next step would be to get a HB_FUNC( GETGETSEL ) working so we can replace selected text.

Thereafter there's only one more thing before fivelinux gets 10 out of 10 for me - setting selection in a BROWSE. I don't suppose there's a similar setting?

Regards
Doug
(xProgrammer)

Hi Antonio

Thanks so much. Its working great here. I'm so grateful I'm almost (but not quite) too embarassed to ask for more ... but ... supporting a double click event on a browse would be nice (and make using the software more efficient). Any chance?

A very grateful
xProgrammer

Re catching a double-click event this might help

http://library.gnome.org/devel/gtk-faq/stable/x545.html

Regards
Doug
(xProgrammer)

Hi Antonio

Just a thought. Since



seems to be updatinga universal setting (and certainly is not directly attached to any particular object of Class TGet), I was wondering if it might not be better to just stick it in TWindow and TDialog classes.

Perhaps we could use some standard define to activate it so people can program either way. Perhaps if you include



then it is included in any TWindow/TDialog. Or do it the other way around with this as the default behaviour.

Regards

Doug

Doug,

The idea is to set it only when we use TGet objects

If we don't use a TGet then there is no need for such setting (?)

Anyhow, we could create a C wrapper to set those settings from PRG level

Hi Antonio

> Anyhow, we could create a C wrapper to set those settings from PRG level

Yes, you're right, that would be the best approach of all. Having it in TGet works fine but it would be better to just call once rather than for every single GET.

Regards
Doug
(xProgrammer)

Hi Antonio

I had a second thought on the above. What if we made it a method of class TWindow. Then it could be called from any of the FiveLinux gui classes by inheritance, couldn't it. That way it could be changed during execution if desired. A single call to the opening TWindow or TDialog object should suffice in most circumstances.

Whilst considering that, isn't that also the best place to put functions controlling color settings. Currently I have them for class TButton because that was the first type of object I needed to control the color of. But now I also want to control the color of objects of class TGet. This can be made to work with the c code sitting in buttons.c because there is no actual tie between button.prg and buttons.c. But color settings can pretty much apply to objects of all the gui classes.

Regards
Doug
(xProgrammer)