TextEdit resizing

I have problems and hopefully someone has answers or knows where to
look for answers.
I am using TextEdit views within a ContainerView which in turn resides
in a ShellView. I wish to give the user possibility to resize these
TextEdit views but still keep their ordinary behavior. The ultimate
solution is if it is posibble to grab the bottom of a TextEdit and
drag it up or down and at the same time prevent overlapping of other
TextEdit views within the ContainerView.
Problem 1: Possibility to grab the bottom of a TextEdit view and drag
it up or down.
Problem 2: Track the dragging and prevent overlapping.

I am running Dolphin XP 5.1

Hopefully I have made my problems clear enough for you to suggest
solutions.

Regards,
JanneL

> Problem 1: Possibility to grab the bottom of a TextEdit view and drag
> it up or down.

The easiest solution is to use a splitter, unless you are trying to
provide a "forms editor".


> Problem 2: Track the dragging and prevent overlapping.

IMHO, if your users are sufficiently savy to stay out of trouble when
given the opportunity to drag subviews, then they can probably be
trusted  to deal with overlapping, and will likely see temporary
overlapping as a feature rather than a defect.

The closest thing to what I _think_ you are describing is the
ViewComposer.  Its use of a transparent shield view is probably the
easiest way to allow mode-specific mouse interaction with subviews.  An
alternative would be to (re??)subclass the controls in the Windows
sense, but I prefer the shield.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Thanks for trying but it is hard to make me happy.
Maybe it had been better if I had tried to explain what I wanted to
achieve. Scheduling of activities.
The ContainerView represents a given time-period i.e. a month scaled
per day and the TexTEdit subviews are representing activities that
last for a couple of days. The resources used by an activity are
unique so overlapping is not permitted. And further more the
activities are not supposed to be carried out each day, which means
that a Splitter will not work, as it requires the parentView to be
under control of a ProportinalLayout Manager ( at least as I
understand it ).
The TextEdit subviews are supposed to show both data i.e.
activity-name and graphically which days the activity is carried out.

Regards,
JanneL

JanneL wrote:

> The ContainerView represents a given time-period i.e. a month scaled
> per day and the TexTEdit subviews are representing activities that
> last for a couple of days. The resources used by an activity are
> unique so overlapping is not permitted. And further more the
> activities are not supposed to be carried out each day, which means
> that a Splitter will not work, as it requires the parentView to be
> under control of a ProportinalLayout Manager ( at least as I
> understand it ).

I'm finding it difficult to visualise this, and I suspect other people may be
too.  If you don't get an answer that helps then you could try posting a link
to a screenshot of what you are trying to achieve.  (Post a link, don't attach
the screenshot to the message because most news servers won't carry it.)

However, my best guesses are that you don't want to use a ProportionalLayout
either because you need a more complicated layout than ProportionalLayout will
handle, or because you want to leave "gaps" between the components to represent
periods when nothing is scheduled.

If the first guess is correct, then Steve Waring's website has a page on using
Splitters with a FramingLayout,
    <http://www.stevewaring.net/blog/articles/tipFrameSplitter.html>
which may help.

If the second guess is correct, then I think I'd handle it by putting blank
Views (perhaps a static text with no text in it) in to represent the gaps.
(I've added a little script that you can execute in a workspace to show what I
mean)

I doubt if either guess /is/ correct, though, which is why I think a screenshot
would help.

    -- chris

======== mock up ===========
days := #( #(1 2) #(3 6) #(9) #(15 17) #(20 25) ).

shell := Shell show.
shell view
 extent: 400@800;
 layoutManager: (ProportionalLayout new beVertical);
 caption: 'Mock-up'.

last := 1.
days do:
 [:each || size p |
 each first > last ifTrue:
  [| v |
  v := shell view addSubView: StaticText new.
  v arrangement: (last - each first / 31).
  shell view addSubView: Splitter new.].
 p := RichTextPresenter createIn: shell.
 p view
  arrangement: (each last - each first + 1 / 31);
  text: ( each first displayString , ' to ' , each last displayString).
 last := each last]
 separatedBy:  [shell view addSubView: Splitter new].

Thanks !

But as I said last time it is hard to make me happy. I will see if I
can use your solution with dummy-activities in between the real ones.
Since last time I have been doing some experiments with THICKFRAME and
at first it looked quite well. But new problems showed up, such as
missing messages in the View MessageMap. Are there any good examples
showing the mechanism of manipulating the MessageMap.


Regards,
JanneL

> Since last time I have been doing some experiments with THICKFRAME and
> at first it looked quite well. But new problems showed up, such as
> missing messages in the View MessageMap. Are there any good examples
> showing the mechanism of manipulating the MessageMap.

I did this once for PenWindows, and it (the mapping, not PenWindows) worked
well.

The most important thing is to ensure that the handler method exists
whenever the message number is mapped; so define the method first, and
undefine (uninstall) last.  IIRC, there is a little more detail on the Wiki,
but I'm not getting a response from it at the moment.  There should be
something in Ian's archives.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]