StdioFileStream oddity

Greetings,

after owning Dolphin for quite a long time, I finally get paid to do
some work in it.

While looking for the right class I came upon:

StdioFileStream>>read: aString text: aBoolean
  ^self basicNew
    setStream: (CRTLibrary default
      fopen: aString
        mode: (aBoolean ifTrue: ['rb'] ifFalse: ['rt']))
    isText: aBoolean

It seems as if 'rb' and 'rt' have to be switched in the mode: argument.
As I don't have much experience doing windows, I don't know, if that
really makes a difference.

Regards,
Stefan

Stefan

You wrote in message news:[hidden email]...
> Greetings,
>
> after owning Dolphin for quite a long time, I finally get paid to do
> some work in it.

Please tell us more. We are always interested to hear how Dolphin is being
used.

You are right, it is inverted. Thanks.

Regards

Blair

On Fri, 11 Jan 2002 23:00:35 -0000,
Blair McGlashan <[hidden email]> wrote:
Hi Blair.

It's a program for keeping track of sales and purchases made by a local
clothes dealer here ... it's replacing a cobol-program some 15 years old.

I appreciate the Dolphin environment very much, as it is comfortable without
getting in my way, except for the View Composer, which is clumsy to use for me.

I even found out how to kill those generic comments for
generated accessors, took only about 10 minutes, plus now my accessors are
public by default ... I've been bragging about this to a colleague ever
since :-) Not about me being clever enough, but about the language and
the environment for allowing the modification.

Since it was my first *real* work in Dolphin, I had the usual difficulties
with setting up my first MVP triad, but the second one was much easier
already. Ted's book helped a lot in this regard, though I wish, I had
had it three weeks sooner ... might have saved some hair this way ...

What's on my mind right now is the following:

The system consists of several components: administration of suppliers,
purchases and sales, plus some statistics to aid in deciding what to
buy for the next season.

The easiest way for me would be to provide a ShellView or DialogView
for each of these components as I know how to do this already :-)
But this will result in lots of open windows, which will be confusing
for the intended audience. So I came up with the idea of displaying
a TreeView on the left hand side showing the various options.

(Yes, usually you do this with menus, but the possible choices are few
enough to be displayed all at once, so the customer sees a structure
and switches components with only one click.)

What I have not yet managed to do is changing the view in the right
hand side of the window according to the selection made in the TreeView.

I'd be thankful for setting me on the right track here.
 
thanks,
s.

--
Stefan Schmiedl
EDV-Beratung, Programmierung, Schulung
Loreleystr. 5, 94315 Straubing, Germany
Tel. (0 94 21) 74 01 06
Public Key: http://xss.de/stefan.public

shhhh ... I can't hear my code!

<snop>
I even found out how to kill those generic comments for
generated accessors
</snip>

Do tell!

jlo

Jeffrey,

> <snop>
> I even found out how to kill those generic comments for
> generated accessors
> </snip>

Error: Missing </snop>

> Do tell!

Judicious editing of ClassDescription>>generateAccessorMethods: would seem
in order.

Ian

Stefan,

> What I have not yet managed to do is changing the view in the right
> hand side of the window according to the selection made in the TreeView.

Which bit are you having trouble with?. If it is "recognising when the tree
selection has changed" then the following might help. However, if it's the
"changing the view" bit causing the problem  then it does depend on how you
are setting up your shell and what you are trying to put in the right hand
view. Ask again if this is the case.

When the selection is changed in the tree view it's associated TreePresenter
fires off a #selectionChanged event. Your shell (the one containing the tree
MVP and whatever you have in the right hand side) listens for this event and
updates the right hand side according to the selection.

MyShell>>createComponents
    ...
    myTree := self add: TreePresenter new name: 'my tree'


MyShell>>createSchematicWiring
    ...
    myTree when: #selectonChanged send: #onTreeSelectionChanged to: self


MyShell>>onTreeSelectionChanged
    | selection |
    myTree hasSelection
        ifTrue: [self fillRightHandViewFor: myTree selection]
        ifFalse: [self clearRightHandView]

However the final method, #fillRightHandView:, which fills the view
according to the selected item in the tree looks to me like it will end up
being a bit too procedural, a sort of "case" statement.  Probably something
to be avoided.

I don't know how many options you have but I would think a tab view, each
tab containing a different aspect of your application, might be a better
solution. You could then make each tab view a separate MVP triad (with the M
possibly shared). It does depend on what you want to do though.

Regards
    Ian

Hi Ian,

On Tue, 15 Jan 2002 20:53:13 -0000, Ian Bartholomew <[hidden email]> wrote:
I am asking again, as I got the tree part almost exactly like your solution
below.

will not, as I will use a Collection of Associations or some other
clever data structure to avoid this thing ... If it weren't for those
stupid umlauts, I could use the displayed strings as class names
themselves ...

>
> I don't know how many options you have but I would think a tab view, each
> tab containing a different aspect of your application, might be a better
> solution. You could then make each tab view a separate MVP triad (with the M
> possibly shared). It does depend on what you want to do though.
>

The problem with tab views is that they are linear and not hierarchical.
I wanted something like the following:

Shop
|
+-- Core data
|   |
|   +-- Suppliers
|   |
|   +-- Groups
|
+-- Inflow of Goods
|
+-- Outflow of Goods
|
+-- Statistics
    |
    +-- summarize for suppliers
    |
    +-- summarize for groups
    |
    +-- supplier-group-crosstab

If you clicked on Shop, you got some general evaluation for the
last eight seasons, very rough, just to see, if you're in the green.

Suppliers and groups are basically just associations between some number
and a name. They should be displayed on the right as a list, maybe with
some additional info as who appears in which seasons.

Inflow and Outflow will be some "normal" input dialogs streamlined
for this particular shop ... the *never* sell two identical items
in one transaction, so the number of items sold is preset, etc.

It was a bit more than that, but after installing a linux box with ISDN-card
as Faxserver for the first time tonight, I am a little bit tired ...

But basically, I am looking for a painless, nay, elegant way to display
different views in the right hand side of the window. Right now I am
building those components as ShellViews, just so that I have something
to show and test for basic usability.

IIRC, Delphi can do something like that: you put some controls into a "frame"
object and then use that frame with all of its subcontrols as a single item.

What crossed my mind: put up all of the possible views and reorder them so
that the "right one" is visible in front ... or maybe do show/hide as the tree
selection is changing.

But it does not feel right... that's why I am still looking for some better
solution.

s.

Stefan,

> But basically, I am looking for a painless, nay, elegant way to display
> different views in the right hand side of the window. Right now I am
> building those components as ShellViews, just so that I have something
> to show and test for basic usability.

Have a look at the pane holder on Bill Schwab's Smalltalk web page

http://needle.anest.ufl.edu/anest4/bills/Smalltalk.htm

It may not be exactly what you want but should give some ideas. You can
change the pane within a Shell dynamically. As a demo evaluate the following
one at a time (after installing Bill's classes obviously :))

"Creates and displays outer Shell"
p := PaneHolder show.

"Displays n EtchASketch MVP within the Shell"
p createPresenterOfClass:EtchASketch onModel: EtchASketch defaultModel.

"Now displays a MethodBrowser within the Shell"
p createPresenterOfClass:MethodBrowser onModel: MethodBrowser defaultModel

IIRC, the only proviso is that the inserted Presenter cannot be a Shell
subclass.

If you add the PaneHolder as your right hand view than a change of tree
selection can instigate a change to the presenter the PaneHolder is
displaying.  You might have to play about with the Models, caching them if
you don't want a new one every time the Presenter is selected, but it
shouldn't be too hard?

Another example are the Dolphin Inspectors. These have an outer, owning
Shell, that can dynamically change the Presenters they are displaying. It's
a bit convoluted but see Inspector/InspectorShell and
Aspect/PublishedAspectInspector for details.

Regards
    Ian

Hi Stefan

>
> > But basically, I am looking for a painless, nay, elegant way to display
> > different views in the right hand side of the window. Right now I am
> > building those components as ShellViews, just so that I have something
> > to show and test for basic usability.
>

How far did you get in my book? I *think* I'm covering what you want in
chapter 10; section 10.1.3.

Hope this helps,

Ted