[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [StrongED] SetTmp and selected blocks

In message <bb185de553.gavin@xxxxxxxxxxxxxxxxxxxxx>
          Gavin Wraith <gavin@xxxxxxxxxxxxxxx> wrote:

> In message <5a0d52e553.fjgraute@xxxxxxxxx>
>           Fred Graute <fjgraute@xxxxxxxxx> wrote:
> >> I have checked for myself that the StrongED$Tmp_xxx variables
> >> get overwritten every time the SetTmp function is called. This
> >> is OK if you are only working on one textwindow. But sometimes
> >> it would be nice to work on more than one. One might want a script to
> >> take as input not only the state of the window to which it has been
> >> dragged, but also that of another window. For example, select some
> >> text in one window and then drag in a script to another window to copy
> >> the selection, perhaps modified appropriately to suit each
> >> destination, to all the places in the latter window which match a
> >> given pattern.
> > The problem here is that the script is applied to the text by an
> > external tool which knows nothing about StrongED except what gets
> > passed to it in the StrongED$Tmp_xxx system variables. The external
> > tool cannot request an other text be passed to it so the solution to
> > this must be found inside StrongED.
> > Perhaps altering the cs-Drag behaviour, instead of applying it to all
> > texts the script is applied to texts that are selected in the LoW. This
> > would mean a script could be applied to any set of files, including all
> > so that functionality isn't lost.
> > Just an off the cuff idea but it looks do-able. Any comments?
> The current cs-drag behaviour is very useful. It would be good to keep
> it.

It would be kept but with a extra initial step; selecting all the texts.
The LoW menu could be given an additional 'Select' item to help with

> But how about cs-drags to the StrongED iconbar icon doing something
> with all the texts selected in the LoW? The Process command uses scrap
> files.

Dragging to the iconbar icon is for loading things. Applying scripts
this way would be the wrong mechanism, IMO.

> The ProcessLoW command is tied to a restricted set of actions. Would
> it be too expensive to have a different scrap file created for each
> selected text?

In terms of system resources - probably not. The whole process would
have to be atomic so the system may be unresponsive for an extended
period of time.

> Could there be a system variable StrongED$Tmp_LoWSize returning the
> size of the LoW? The script could expect to find in
> <StrongED$ScrapDir> files out1, out2, ... outn where n is the value
> <StrongED$Tmp_LoWSize>.

Such a variable would be possible though you'd have to be careful as LoF
and throwback windows also get listed in the LoW, and multiple views.
It's probably best to exclude TaskWindows too.

However, the variable may not be necessary, the script could simply
process all outnnn files.

> Then the command inside Process need only have in its tail the values
> <StrongED$ScrapDir> and <StrongED$Tmp_LoWSize> as parameters. Does
> that make sense?

Apart from the script being able to see all the texts at once I'm not
sure what advantage this offers over the current cs-drag behaviour.


StrongED Developer

To unsubscribe send a mail to StrongED+unsubscribe@xxxxxxxxxxxxxx
List archives at http://www.Torrens.org.uk/RO/StrongED/index.html