BlackBox Framework Center

Robert wrote:The version of StdApi.ThisMask below fixes both issues.

I've just noticed that the innermost line can be simplified to

Thanks for detailed description. I made the issue for this topic:
http://redmine.blackboxframework.org/issues/93

I understood the idea of automatic mask mode for tabs.
I committed the code to the topic branch.
http://redmine.blackboxframework.org/pr ... 09b8485be8
The test version:
http://blackboxframework.org/unstable/i ... a1.363.zip

However during analysis of the first issue about log message there are some questions appeared.
Why we make this exception for Tabs only? The buttons will still produce such message to log.
Why are you using tabs without container? Does it really necessary?

Ivan Denisov wrote:However during analysis of the first issue about log message there are some questions appeared.
Why we make this exception for Tabs only? The buttons will still produce such message to log.
Why are you using tabs without container? Does it really necessary?

No, I guess it is not really necessary, and the error message to the Log is a very minor problem.

I was developing a complicated radar analysis model in 2009 with very many Controls on some large and busy TabViews. It seemed convenient at the time to develop the model in
parts before combining them, so I was doing much editing / reworking on a couple of Tabs separately before finally putting them onto the main Form. These "error" messages concerned me as I was worried that I was causing a serious error that might cause unreliability later. So I investigated their cause and found there was not a serious problem with my program, and that it was very easy to suppress these distracting messages.

I can live without this (very minor) fixup.

Since Buttons are so simple I also cannot imagine wanting to keep them in separate files, so there is no need to recognize them here.


Regarding the second issue (automatically converting Tabs to Mask mode) I think this is a very useful feature missing from the current Oms implementation.

Robert wrote:Regarding the second issue (automatically converting Tabs to Mask mode) I think this is a very useful feature missing from the current Oms implementation.

So we can vote about this feature already. And I moving it from bugs to features subforum.

I have never used Tab Views so it is a non issue for me.
-Doug

For not braking the abstraction levels we can adopt some idea how to inherit mode settings more general. Not only Tabs, but all embedded views. Or there should be some hook or messages broadcasting in StdApi for embedded views can adopt for container mode.

Right, Ivan, a hook is the way to go! Since the existing mode-related messages are not
sent recursively to nested forms, it would be a much more difficult task to do this
by means of messages and nobody knows about possible side effects.

Therefore I have introduced StdApi.modeHook with the following advantages over the previous approach:
- Avoids import of StdTabViews in StdApi.
- Avoids any change of Build-Tool.odc.
- No special treatment of StdTabViews but allows ANY embedded form to register
for switching to mask mode when opening a dialog.
- Supports any nesting level not only one.
- Could also be used for switching modes e.g. in Dev->XXX Mode.

See the changes in http://redmine.blackboxframework.org/pr ... 092df2173c.

- Josef

Josef Templ wrote:Therefore I have introduced StdApi.modeHook with the following advantages over the previous approach:
- Avoids import of StdTabViews in StdApi.
- Avoids any change of Build-Tool.odc.
- No special treatment of StdTabViews but allows ANY embedded form to register
for switching to mask mode when opening a dialog.
- Supports any nesting level not only one.
- Could also be used for switching modes e.g. in Dev->XXX Mode - Josef

Wow! Some subtle thinking here!
I see how you did the recursion in 1 line - something, as I said, my solution didn't attempt as it would have taken more code (for relatively little benefit).
I once put a TabView on a Tab, but it was too awkward to use so I've never done that again.

The way you have chained several hooks seems subtle to me. I would have had a RECORD with a next field to register several hooks.
Are their other examples of your approach in the Framework, or is it a new idea? (Are their examples of Hooks with next fields, or am I thinking of Converters?)

I am only asking out of curiosity; I am not criticising your solution.

Well I am now! You have misspelt "which" as "whicvh" in Docu/Api.
Robert

Chaining a hook in the presented way is a very old pattern.
I don't know where it came from but I am sure I have not invented it.
I didn't want to add a lot of code with types and methods etc.
On the other side it was clear that chaining should be supported somehow because I found
an alternative tab-views module in an old application that would also benefit from registering itself.

The typo in the docu has been fixed.

- Josef