issue-#101 improvements for the std. properties inspector

[Josef Templ]

This issue proposes to add source link buttons to the standard properties inspector (Dev/Rsrc/Inspect).
When working with forms it is important to have a feature for convenient navigation from
the standard properties inspector (Link, Guard, Notifier) to the related source code.

For the issue see http://redmine.blackboxframework.org/issues/101.

For the source code changes see http://redmine.blackboxframework.org/pr ... 693ed02c62.

For a test version download http://blackboxframework.org/unstable/i ... a1.407.zip.

The proposed solution uses a text search similar to DevReferences but tuned to the needs
of navigation from the properties dialog. It supports qualified identierers of arbitrary depth
and it uses the export mark for skipping unwanted search results.
When navigating to "M.x.y" and y is not found but x is found, it jumps to x, i.e. to the most specific position found.

While it is not a full featured parser (and thereby cannot find all occurrences precisely),
it works well in most practical situations.

In addition, the 'Level' field has been changed to an UpDownField.

- Josef

[Robert]

I haven't looked at this proposal in detail, but have a few higher level questions:

- Would it not also be useful to have an option (the <Ctrl> key ?) on these new Commands that easily opened the Docu rather than the Source of the links?
(In my own Tools I have the convention that Command buttons that support an alternative <Ctrl> key function are called "◊ DoThis" rather than "DoThis".)

- If there is significant overlap with the DevReferences Commands would it be possible / desirable to upgrade those to do both jobs?

- The new procedure "SearchSource" looks generally useful. (I have something similar in my private library which could also be described as "not a full featured parser, but often works adequately".) Should SearchSource be Exported & documented?

Regards

[Josef Templ]

- Would it not also be useful to have an option (the <Ctrl> key ?) on these new Commands that easily opened the Docu rather than the Source of the links?

- If there is significant overlap with the DevReferences Commands would it be possible / desirable to upgrade those to do both jobs?

- The new procedure "SearchSource" looks generally useful. (I have something similar in my private library which could also be described as "not a full featured parser, but often works adequately".) Should SearchSource be Exported & documented?

Regards

When I work on a form I work on my own application which does not have a docu file per module.
Instead it has a docu file for the end user for each dialog.
So navigating to the docu was never an issue for me.

I didn't want to change any of the existing code. This would make it more complicated, I think.
For the inspector it is possible to look at the export marks, for example.
Also it is possible to skip the text until the first VAR or PROCEDURE.
These are vital points for getting good search results. In DevReferences this is different
and it will probably also be different for other envisioned usages of "SearchSource" if it is exported.

Therefore I would not export "SearchSource". It is tuned very much for this special case
and not very reusable.

- Josef

[Ivan Denisov]

I would like to suggest using another symbol on this buttons. Because "..." usually means that some dialog window will open to make a choice or to set up something. So the behavior of interface is unexpected with such a label.
Maybe ">" is good choice or question "?".
Also the button can be disabled until Meta.Lookup does not return any item.
This will give additional value for the feature, because it will check spelling.

[Josef Templ]

I would like to suggest using another symbol on this buttons. Because "..." usually means that some dialog window will open to make a choice or to set up something. So the behavior of interface is unexpected with such a label.
Maybe ">" is good choice or question "?".
Also the button can be disabled until Meta.Lookup does not return any item.
This will give additional value for the feature, because it will check spelling.

I agree. ">" would be better.
It looks very much like an arrow. The "?" would
imply that it points to the docu.

It is also not a problem to add special guards.

I was also thinking about closing the gap for the 'Label' field.
For me it was not an issue so far because I did not use localizable labels.
In the general case, i.e. when using localizable labels, the button could
navigate to the related key in the Strings file.
What do you think?

- Josef

[Ivan Denisov]

I was also thinking about closing the gap for the 'Label' field.
For me it was not an issue so far because I did not use localizable labels.
In the general case, i.e. when using localizable labels, the button could
navigate to the related key in the Strings file.
What do you think?

Not much people use localization, so better not touch labels.

[Zinn]

Not much people use localization, so better not touch labels.

Sorry, that is the wrong argument.
Localization was not much used, because the support on 1.6 was not complete.
Now, Josef had improved this topic very much.
So it make sense to add it.
How would you like to know we needn't it with the new edition?

- Helmut

[Ivan Denisov]

Helmut, I agree with your arguments. It can be used more often if it is easier and well documented.

[Ivan Denisov]

Josef, will you make Notifier by yourself or somebody can help you?

[Josef Templ]

I am working on it.