going with the rtf control route, it looks like there
is a reasonably efficient wd command (cross platform)
to let you update text contents quickly:

setreplace id newtext ; replace selected text with
newtext in edit, editm, richedit, and richeditm
control

should get around your very large file update
concerns. (this is just a guess based on what I'd
expect the api to provide rather than any relevant
experience :)

--- Pascal Jasmin <[EMAIL PROTECTED]> wrote:

> Here is one useful system similar to your proposal
> that maybe slightly easier to implement:
> 
> The concept of a live program file:  Each time a
> line
> is appended, it is sent to the session manager and
> executed.  Any time a line is edited and ctrl-enter
> applied, it (or the multiline definition that
> encloses
> it) is executed. ctrl-alt-enter would erase any
> names
> assigned by that line (alt not documented modifier
> in
> isigraph :(, before executing.  Executing a
> selection
> should also be possible for cases where names  are
> redefined based on themselves (myverb =: myverb f.
> @:
> preprocessingFunction).
> 
> Another concept would be a Run Window Changes
> command
> that would only incrementally execute lines that
> have
> changed since the last Run Window command.
> 
> The real difficulty with either this or your
> original
> proposal, is that there are only 2 obvious
> approaches:
> 
> 
> 1. Implement your own line editor using a canvas
> instead of a text box.  Your own keyboard handler to
> handle scrolling, perhaps a C.dll to handle mouse
> scroll wheel messages (should exist somewhere
> already,
> though cross platform without requiring a GUI
> toolkit
> is unlikely).  A floating rtf box might be overlayed
> on top of a line to handle line editing.  A lot of
> tweaks would be necessary to make behaviour
> completely
> identical from a user's perspective to rtf/textbox
> editing.
> 
> 2. Hook into existing J.exe code, or just an RTF box
> for keystroke messages.  If no native islinedirty
> method for an RTF box exists, a custom one is not
> that
> ambitious if cursor movements and enter keys are
> trapped (on cursor movement, save copy of current
> line. when moving away from a line, check if line
> still matches copy made when it was entered into). 
> Organizing lines in a linked list with line numbers
> just a tangential data point can help handle newline
> commands, preventing them from making all lines
> below
> dirty.
> 
> Incremental processes can be tricky and annoying to
> implement though.
> 
> Regarding your 100MB scenario, there must be an api
> to
> replace and append text in a richedit control in an
> efficient manner.  If not, then typing would be very
> very innefficient.  Its not part of the wd driver
> though.
> 
> Either of the approaches would require wd
> enhancements, IMO. scroll wheel mouse events (if
> first
> approach taken), the ability to peek at/change
> messages before passing them on to a client control
> (unsure if that's currently possible), and either a
> "sendkeys" feature or  extending the wd api to allow
> (fast) insert/appends into rtf controls.
> 
> --- "Miller, Raul D" <[EMAIL PROTECTED]> wrote:
> 
> > I want to build a J form which is essentially a
> > session manager.
> > 
> > In other words, the user will type in a line of
> > text.  The
> > line will be appended to the session.  An
> > application function
> > will process the line.  The result will be
> appended
> > to the
> > session.
> > 
> > Sessions can be large (hundreds of megabytes,
> worst
> > case),
> > but usually only the tail end of the session is of
> > interest.
> > 
> > Sessions will be logged to a file.
> > 
> > Advanced versions may color the text (input a
> > different
> > color from ouput, for example).
> > 
> > How to implement?
> > 
> > One approach has a richeditm which represents the
> > entire
> > session.  This incurs tremendous cost updating the
> > session
> > when the session gets large.  I'm rejecting this
> as
> > unworkable.
> > 
> > One approach has a richeditm which represents the
> > visible
> > part of the session.  A scroll bar would allow
> > navigation
> > within the session.  Arrow keys could not be used
> > for
> > scrolling (no J event handler for them).  Mouse
> > wheel could
> > not be used for scrolling (no J event handler for
> > it).
> > 
> > Any better approaches?
> > 
> > Thanks,
> > 
> > -- 
> > Raul
> >
>
----------------------------------------------------------------------
> > For information about J forums see
> > http://www.jsoftware.com/forums.htm
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> http://mail.yahoo.com 
>
----------------------------------------------------------------------
> For information about J forums see
> http://www.jsoftware.com/forums.htm
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to