Re: Button list control

"Hans-Peter Diettrich" <DrDiettrich@xxxxxxxxxxx> wrote in message
news:40qbj4F198r4kU1@xxxxxxxxxxxxxxxxx
> Maarten Wiltink schrieb:

>>> [...] Perhaps I should add a context menu property to my TXStrings,
>>> so that they can not only be displayed, but also can react, when put
>>> into a control?
>>
>> I think that would be a mistake. The context menu should probably be a
>> property of the memo, not of its contents.
>
> When you use page controls, different context menus may apply to every
> page. In my Abbrevia clone, the applicable options depend on the type
> of the actually displayed archive, not on the container control.
> What's wrong with exporting methods, implemented in a specific class,
> by exporting an according context menu?

But in a different program, it would probably have different options.
I'm not against associating code with data - it's a very OO thing to do.
But a complete context menu just looks like to big a chunk to me, with
too much baggage. Like menuitem captions: what if the application had
to be translated?


> [...] In such a modular approach the number of modules
> (plug-in's) can be extended at any time, and it's only convenient when
> the main application must not be updated to reflect the capabilities
> etc. of every added module.

I've used plugins in an application once but it had a single "action"
per DLL, and they didn't suggest any integration information (menuitem
caption, shortcut key, and location; toolbar button, hint, and location).
You had to decide on that yourself when plugging it in.

The main application will have to be updated in _some_ way, or you can't
get at your plugins. But there's room for many choices here.



>> Actions, I now suspect, are [in] between business objects and user
>> interfaces. The BO's methods have parameters, actions combine BO
>> methods and draw the required parameter values from the user interface.
>
> And actions also are capable of finding their related BO's in the GUI.

Yes. I imagine something like querying a context for the relevant
selection, which consists of a BO or BO collection. Actions are
firmly tied to both BOs and UI.


> Somebody specifies the actions for the application, somebody else
> designs the forms, more guys implement the business objects, and the
> actions finally connect the related things in the actual application.

Some day, I'm going to be all grown-up and work in a team with more than
one other developer. And I'll probably hate it.



[...]
> IMO the state space of the application is more important than the state
> (space?) of the UI. Oh, do I see another soap box slipping into view?

Soap boxes are _good_. That assumes that strong opinions can also be
strongly defended.

What, exactly, makes an application? The business objects form the
foundation upon which it has to be built; you can't make a system that
does things its data can't handle. The user interface is merely a
choice of how to present data and operations to the user.

In practical terms, which tab is visible determines what data you
can enter and what will be done with them. If the "overview" tab is
visible, you can enter search criteria and transactions satisfying
those criteria will be listed. Search criteria and transactions are
business objects; tabs and listboxes are UI. Which tab is active and
which transaction in the list is selected, are state. But BO state,
application state, or UI state? To me (and you are very much invited
to disagree), the tab selection is UI state and determines that the
"DisplayProperties" action is enabled, and the selected transaction,
the one whose properties will be displayed, is a UI state attribute
also.

The transaction also has a state (for example, that it has been
requested but not yet refused or committed to), and this influences
the state of other actions such as RefuseTransaction. But from the
other side, the BO side, not the UI side. The BO side isn't as
controversial as the UI side. Designing actions requires the BOs
to be fixed, but there can be as many UIs as there are people.


>> But an explicit context object might well be a good place to look for
>> the selection that's relevant in this context. It might do no more
>> than retrieve it on demand from elsewhere, but it certainly feels like
>> a good way to organise code.
>
> I came across that idea in an attempt to reduce the degrees of freedom
> in the state space of applications. A program can be managed in levels
> of state spaces, with less degrees of freedom in every higher (more
> abstract) level. Then the relationships and requirements can be managed
> and handled easier in the higher levels, and in the lower levels the
> view of the "outer" world can be reduced into distinct states, instead
> of complex state spaces.
> [Not sure whether I could explain my thoughts well enough]

It certainly conjures up images. Contexts form a hierarchy. A smaller
context means more is known about the world.

I'm not exactly clear on the relationships and requirements. Between
what, on what?

Groetjes,
Maarten Wiltink


.

Relevant Pages

  • Re: Using COM+ through EnterpriseServices
    ... public void BeginTrans(int DBType) ... // get appropiate transaction context on which to commit ... we use the attribute to control the transaction creation. ... > Disabled Ignores any transaction in the current context. ...
    (microsoft.public.dotnet.framework)
  • RE: Warning messages in Tlbimp
    ... I think in .NET we use the attribute to enable Transaction. ... We use the TransactionOption as below to control whether the component will ... Disabled Ignores any transaction in the current context. ... Microsoft Online Partner Support ...
    (microsoft.public.dotnet.framework)
  • Re: raising Page event with customs webcontrol
    ... Context, which would be raised when there's no associated http context e.g ... inside a control you can get to the HttpContext yourself via ... > through the registering of the control to raise events and place a public ... > and they will have Page level scope context. ...
    (microsoft.public.dotnet.framework.aspnet.buildingcontrols)
  • RE: Maintaining State Between Web Pages
    ... The server will run on a client machine. ... In addition to the threading model, ... such as a receipt object to record the transaction. ... When a transactional object is created from an existing context, ...
    (microsoft.public.scripting.vbscript)
  • Re: TypeConverter Question
    ... >> have a property whose type is Control. ... >> public override bool GetStandardValuesSupported(ITypeDescriptorContext ... >> context) ... >> public override object ConvertFrom(ITypeDescriptorContext context, ...
    (microsoft.public.dotnet.framework.aspnet.webcontrols)