Subj : Re: Internal codes in Baja
To : Tegularius
From : Digital Man
Date : Mon Jul 06 2009 04:39 pm
Re: Re: Internal codes in Baja
By: Tegularius to Jas Hud on Mon Jul 06 2009 01:38 am
> Re: Re: Internal codes in Baja
> By: Jas Hud to All on Sat Jul 04 2009 17:40:52
>
> >
> > i think i have a better idea. why dont you just keep the current
> > listings and then draw ansi files for each file sub? that way you could
> > control clutter and 'scrolling'
> >
> I'm planning on it. The only drawback is that the file area must still
> be selected by number, right? What I would like to do is allow the user
> (in some cases) to choose the area using a mnemonic letter or string of
> several letters, which are highlighted in each menu.
>
> By the way, the kludge I mentioned wanting to try works! Sometimes it is
> slow, because it involves executing an external program.
>
> Also by the way, I was considering the possibility of alternate file paths,
> if only because the docs say somewhere that each file area defined takes
> up RAM. Do you know how much RAM, or at what point this might begin to
> be a problem? Vertrauen must have well over a hundred. I recall from
> three years ago (before my disk crash) I was offering the contents of
> at least a dozen CDs, each as a library, and most of them had at least
> thirty areas. I don't recall that performance suffered. The trouble with
> alternate paths is that adding more than about eighteen in scfg is a real
> pain because the window keeps bouncing back to the eighteenth. Perhaps
> this is a bug easily fixed?
In 32-bit versions of Synchronet, the memory usage, in general, is not a
concern. Alternate file paths were created to serve an organizational purpose
(not to save memory). I'll look into the SCFG problem you mentioned.
digital man
Snapple "Real Fact" #14:
Camel's milk does not curdle.
---
� Synchronet � Vertrauen � Home of Synchronet � telnet://vert.synchro.net
