Re: Button list control

Maarten Wiltink schrieb:

The main app
can load all DLL's, found in a given directory, and the plug-ins
will register themselves for further use. Implementing 7zip, or some
other new compression format, only requires to add the according DLL
to the app's directory.



I have to admit I don't know the first thing about Abbrevia. What does
"implementing" mean? Drop a DLL in a directory, and you can now unpack
7zip files?

In my version of Abbrevia, yes. But the DLL must implement the common plug-in interface of the application, there exists no magic to make existing DLLs usable without appropriate adaptation.

How much work is the plugin supposed to do, and where does
the host application come back into play?

The plugin is instructed by the host application, what to do, and it has to implement everything specific to an action. The host application can retrieve information from the plugin, present it to the user, and pass the user's commands and parameters back to the plugin.


If a plugin implements more than one command, how are these presented?

This depends on the particular commands. The plugin can e.g. implement it's own GUI, for non-standard commands, or commands with specific arguments. The archive related commands, however, can be standardized well enough, so that the host app implements the whole (G)UI. As already mentioned, I also could imagine that the plugin provides a menu, from which the user can select commands, without specific integration into the host application.


I ask because once upon a time, I had to make all these choices without
any star to steer by. The application came out very nice if I do say so
myself, but there were some quite obvious limitations that for example
Photoshop would not have. Probably.

I'd use packages for plugins, so that shared objects can be used in the communication between the host and client, avoiding problems with different class types, memory managers etc., as occur between a bare DLL and the host app.

.... 
They're not? I'm trying to think of one, but Delphi, Visual Studio,
Turbo Pascal, PCTools, DiskEdit and the like all seemed to conform to
my worldview of displays, entry forms, and actions. (Displays and
entry forms may be merged. That doesn't change anything fundamental.)

Well, I came across the state problem, when thinking about the proof of correctness of programs. It's almost impossible to perform such an proof across an entire program, due to the many possible states of many components. But it should be possible to proof the correctness of every single component, provided that it's dependencies from the outer world can be reduced to an sufficiently small and well defined set of conditions (constraints?).


The way I see it, BO state and UI state simply have nothing to do with
each other. Nor do BO and UI elements touch each other directly. The
actions are the linking factor; perhaps the best way to see it is that
application state is actions state plus UI state, with the user interface
considered the more volatile and arbitrary part of the two.

Consider complex transactions, which must be confirmed at the end, if everything went right, or which must be undone as a whole, if some severe problem occured somewhere. IMO an application can be in several states, during such a transaction, with the option of bringing it back into an valid state, be into the original or into an modified but valid and stable state.


Okay... things like constraints on the state of BOs? Interstrictions?
Application-level solution strategies?


All of that, I assume...


Ugh. Wizards. As I see them, *they* are the deterministic automata. I'd
much rather have all the options visible at the same time, be allowed
to navigate freely between them, see what happens when I change something
in one place, and have a large GO! button in a corner.

A wizard IMO *should* be a nondeterministic automaton, since this is the way how experts work: you cannot be sure, *how* they find a solution, but you can be sure that a solution is correct, with regards to the applicable rules, constraints etc.
Parser generators frequently construct an NFA from the grammar, then explode it into a much bigger DFA, for better performance. Otherwise much lookahead, backtracking and other techniques may be used, with some overhead at runtime. Applications instead are not normally derived from a grammar (formal description of states and transitions), even if sometimes it were better to start with a complete formal description ;-)
That's why we typically need tests in an application, so that we can at least *react* on unexpected situations. But who can know *exactly how* to recover from every single exception, in every possible state?

DoDi
.