Hi

I added a FilterEdit control to the Options dialog which is used for IDE Options and for Project Options.
It searches from all captions form all options pages, highlights the matching texts and hides pages without matches.
Please check out.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120303/787e8def/attachment.html>

The splitter now behaves strange:

- filter is not affected by splitter
- splitter does not obey min-width of tree

Long needed feature. great.
but:

1) It keeps the current frame visible, even if it does not match. That means a frame, that is not in the Tree is visible

2) It would be good to also search list/tree in the frames, like
- the names of colors on "env" > "Form Editor"
- the names of colors on Editor>Colors
- keymapping
- editor/codefolding
- debugger general, property grid (same on "help")
- dbg, exception list

2b)
- dropdowns/checkboxes are searched, but not highlighted
- same for group-boxes / toolbar buttons

3) does not search text in radio buttons (e.ge Editor/ mouse)

4)
Hints are not searched

While it is really fast, maybe as an optimization (if not done already, I did not see any check like it), for any frame, that is not currently visible, it is enough to go for the first match.
(but it must then be highlighted if selected)

2012/3/3 Martin

1) It keeps the current frame visible, even if it does not match. That means a frame, that is not in the Tree is visible

I improved it. There is still a bug in TreeView. A Node's selection is removed when it is hidden (Visible:=False) but it does not work. TreeView.Selected still returns the old selection. Must be debugged at some time.
Anyway it is pretty OK now.

I also fixed the splitter issue mentioned earlier.

2) It would be good to also search list/tree in the frames, like

There was a simple search in Caption strings.
Now I gave special treatment to ListBoxes, although their items are not colored yet.
TreeViews and Grids are tricky, they need much work. In fact the FilterEdit is filtering a TreeView but now we find other TreeViews under the component hierarchy.
SynEdit can't be used in IdeOptionsIntf at all because the dependency is to wrong direction. It should be refactored somewhere else.

CheckBoxes and GroupBoxes are highlighted at least on Linux + GTK2. Maybe a widgetset issue.

3) does not search text in radio buttons (e.ge Editor/ mouse)

It does here.

4)

Hints are not searched

That would be confusing wouldn't it?

Could you please look at
TAbstractIDEOptionsEditor.ContainsTextInCaption
You may know how to search and highlight some of the controls.

About the optimization, I don't think it is worth the extra complication. Iterating the controls is pretty fast.
Maybe later when there is nothing else to do...

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120304/40bd596c/attachment.html>

Thanks.

Why do we need SynEdit?

seems you are right, I must have done something wrong then.

Why?

Could you please look at TAbstractIDEOptionsEditor.ContainsTextInCaption You may know how to search and highlight some of the controls.

Will do later.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120303/a8c614b5/attachment-0001.html>

2012/3/4 Martin

Why do we need SynEdit?

I thought it is used in some options frames. I am not sure.

Hints are not searched

Hints can be long and there would be no immediate feedback about what triggered the filter's match.
The user could think the filter found pages that it should not find. Besides, the filter would not be so useful any more for words and phrases that are used in many places.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120304/2e843243/attachment.html>

Yes, hints can not be highlighted.
But hints can contain additional good words to search for.

Searching for very common stuff is a problem anyway. Typing "e" in the filter returns a lot.

Alternatively, each page could define keywords.

The feature is already great. And I do by no means want to make it look like I do not like it. I like it a lot.
I just expect users may not search or the terms we use for description... We anyway have very few hints currently...

MAybe wait for feedback first, let users tell us what they type to search....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120303/e44ebb52/attachment.html>

2012/3/4 Martin

Thanks for the positive feedback.
This filter has one more nice feature: it supports translated IDEs automatically because it reads the captions.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120304/04b6c5eb/attachment.html>

I tested this filter on Windows and yes, only labels are highlighted. Checkboxes, Groupboxes, RadioGroups etc. are not.
It makes a very big difference compared to Linux + GTK2 or QT. Is this only a missing feature in LCL-Win bindings or is there a more fundamental problem?

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120304/aada1ea7/attachment.html>

I think that font color cannot be chaned for some controls under win32 (but I'm not 100% sure).

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120304/2c77fee4/attachment.html>

You removed he check what color a control was before highlight.

Now links loose their color.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120304/3f962698/attachment.html>

Probably, but it does not seem documented
http://wiki.lazarus.freepascal.org/Lazarus_known_issues_%28things_that_will_never_be_fixed%29

And the restriction browser only shows carbon restriction (for font) -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120304/abccbc93/attachment-0001.html>

2012/3/4 Martin

You removed he check what color a control was before highlight. Now links loose their color.

Now the original state is memorized and restored.
I ended up changing the color highlight, which is distinctive and easy to notice, to font style = Bold + Italic, which is more boring but it works on Windows.

Neither Color nor Font.Color are respected on Windows. It should be possible, I have seen colored GUIs in other Windows programs. Does anyone have a plan to fix it?

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120304/e58b6446/attachment.html>

Neither Color nor Font.Color are respected on Windows. It should be possible, I have seen colored GUIs in other Windows programs.

A ComboBox should react on WM_SETFONT. Also CB_SETITEMHEIGHT should be usable to set its Height to an arbitrary value, differently for the edit box and the list.

Does anyone have a plan to fix it?

Which interface methods are involved?

DoDi

05.03.2012 2:11, Juha Manninen ?????:

Neither Color nor Font.Color are respected on Windows. It should be possible, I have seen colored GUIs in other Windows programs. Does anyone have a plan to fix it?

This depends on windows. When your application supports themes they must be respected. You can ask windows to change the color but windows simple ignores this.

Best regards,
Paul Ishenin.

2012/3/5 Hans-Peter Diettrich

A ComboBox should react on WM_SETFONT. Also CB_SETITEMHEIGHT should be usable to set its Height to an arbitrary value, differently for the edit box and the list.

ComboBoxes are currently not even included in the filtering of Options dialogs.
RadioButton, CheckBox and GroupBox are the problem. There are so many of them and they have caption text just like Label has. It is not very logical that Label can be colored but the other not.

Interface? I don't know. I am talking about TControl.Color and TControl.Font.Color.
If you know how to fix it, please tell me.

It may be related to themes as Paul Ishenin mentioned, but I have seen colors used in other GUIs.
Besides, why can Label be colored then?

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120305/88b78742/attachment.html>

Labels are drawn by the LCL itself (AFAIK), while components like TCheckBox etc. are not.

Regards,
Sven

It may be related to themes as Paul Ishenin mentioned, but I have seen colors used in other GUIs.

Probably those GUIs are custom-drawn, but you are using native widgets in your GUI.

If you want unrestricted colouring options you can use TCDCheckBox and friends from our custom drawn controls units in the LCL:

http://wiki.lazarus.freepascal.org/Lazarus_Custom_Drawn_Controls

But it should be used with care since it might look different then the other nearby controls.

The controls Juha is talking about are those of the IDE's Options dialog. So I don't know whether custom drawn controls are an option there...

Regards,
Sven

2012/3/5 Sven Barth

The controls Juha is talking about are those of the IDE's Options dialog. So I don't know whether custom drawn controls are an option there...

Exactly.
Felipe, did you look at the filtering in the Options dialog? The code just iterates all TControls in all settings frames, changes caption text color if the text matches, and finally hides entries to frames which didn't have matches.
Simple and elegant, except that it does not work on Windows!

Now I have changed it to use Font.Style instead of Font.Color. Color would be a more distinctive and stronger tool here.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120305/61d2fd42/attachment.html>

2012/3/5 Juha Manninen :

Exactly. Felipe, did you look at the filtering in the Options dialog?

Aha, so it affects the entire dialog. Well, at least bold is supported.

Thus it may be a bad idea to use themes in the IDE?

DoDi

05.03.12 21:04, Juha Manninen ?????:

It may be related to themes as Paul Ishenin mentioned, but I have seen colors used in other GUIs.

Please give an example of other GUI. I will check that and maybe correct LCL if possible.

Best regards,
Paul Ishenin

2012/3/6 Paul Ishenin

Good question. I remember seeing it even MS Office somewhere. I don't use actively Windows now and my memories about this are old. Many programs may have used custom drawing for their colorful controls.

I found a Real Studio forum post about the topic. Someone claims :

" Visual Basic 6.0, Delphi and Microsoft Visual Studio allow to set the ForeColor and BackgroundColor for CheckBoxes and RadioButtons. Unfortunately RealBasic does not have this option. "

http://forums.realsoftware.com/viewtopic.php?f=1&t=15458&start=0&st=0&sk=t&sd=a

It didn't say which Delphi version.

I don't know if the color support is a standard feature in these controls but surely it feels illogical that setting a color doesn't do anything. The same color property works with other widgetsets. If it is not supposed to work on Windows it should be mentioned as a restriction.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120306/4d1ffc73/attachment.html>

06.03.12 18:30, Juha Manninen ?????:

I don't know if the color support is a standard feature in these controls but surely it feels illogical that setting a color doesn't do anything.

Color property on windows depends too much on theme engine. Some colors may work on XP but does not work on Vista themes. Some colors does not work on XP too.

The same color property works with other widgetsets. If it is not supposed to work on Windows it should be mentioned as a restriction.

It may be mention there as may not work.

Best regards,
Paul Ishenin

A quick test using Delphi 2007 on Windows 7 (active Aero) shows: Neither Color nor Font.Color are respected for TRadioButton and TCheckBox. For TComboBox both are respected if the list is not csDropDownList (otherwise they are ignored as well).

Regards,
Sven

I just tested with the "turbo Delphi" (the one that was free a few years back).
On Vista, tha same PC where Lazarus does not obey colors.

radio, checkbox, combo. All respect font.color

AFAIK the special thing about Delphi 2007 was Vista support so such GUI things may have changed between Turbo Delphi (which is a Delphi 2006) and Delphi 2007.

Regards,
Sven

Juha, great work with this filter!

it will help a lot!

2012/3/6 Sven Barth

2012/3/7 William Oliveira Ferreira

Juha, great work with this filter! it will help a lot!

Thanks :)
I have sprinkled the filters around Lazarus GUI.
Now it is relatively easy when there are reusable components for it.

Juha

P.S.
Nice photo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120308/e8824e01/attachment.html>