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
