On Thu, 08 Nov 2001 03:11:26 -0400, Clarence Verge wrote:

> On Wed, 07 Nov 2001 20:38:25 -0400, Glenn McCorkle wrote:

>> On Tue, 06 Nov 2001 23:14:56 -0400, Clarence Verge wrote:

>>> So what's the score there ? I know you have been deeply into Insight
>>> recently, so did you mean to say that when you hit the back button
>>> to get from your current mail to the index, it is CORE that regenerates
>>> the damn index all over again ?

>> To see what's going to happen (and whether it will be insight or core that
>> does it), have a look at the status bar in the lower left of the screen.

>> If it shows the name of  a DGI... insight.
>> If it shows no DGI name..... core.
>> (you'll need to get out of full-screen mod to see it) <g>

>>> I guess that also could explain what happens when you hit the "Index"
>>> button: file://inbox.dgi again.:((
>>> So howcome hitting the "I" hotkey takes a shortcut ? (no regenerate)

>> file/inbox.dgi       >HTM|[130]$einsight.exe -i $M*.cnm -cache=$t>$2

>> Before running insight.exe, core first checks to see if the inbox index
>> already exists. (this applies to anything we do in Arachne)

>> If it does not exist, control is passed to insight so that it can be
>> created. Control is then passed back to core so that the resulting HTM
>> can be viewed.

>> If the file already exists.... control is not passed to insight but
>> rather the existing file is viewed by core.

> Ahah! That means it IS Insight that ignores the existence of the already
> generated index then ?
> Don't you wish this had come up before your recent improvement to Insight ?
> <G>

 Nope.

Insight can't make the decision one way or the other as to
either "ignoring" it or paying attention to it.
(all insight does is to go right ahead and do what core tells it to do)

Core makes the determination as to whether or not to have
insight create the index file.

1) file exists..... display it.
2) file does not exist..... tell insight to create it.
3) file exists but for some unknown reason core did not see it.... tell
   insight to create it
(therefore overwriting the one that was already there)

---- simulated .BAT file -----
if exist inbox-index-file goto display-it
:create-it
tell insight to create inbox-index-file
:display-it
if exist fullmoon goto create-it
tell core to display inbox-index-file
if "R" key pressed goto create-it
______________________________

Now all I need to do is to find that D**M "fullmoon line" in the code
for CORE.EXE and remark-out that line. <VBG>

---- "fixed" simulated .BAT file -----
if exist inbox-index-file goto display-it
:create-it
tell insight to create inbox-index-file
:display-it
rem if exist fullmoon goto create-it
tell core to display inbox-index-file
if "R" key pressed goto create-it
______________________________

It just occured to me what one possible cause might be for core not
seeing the index.

 The inbox is actually an HTM file which is stored in the cache
directory. If the cache index file itself has more than 256 items
in it..... than the oldest ones will begin to be deleted from the cache
directory.

1) view inbox
2) view message #1
3) view message #2
4) view message #3
5) view message #4
6) view message #5
7) view message #6
8) take a link that was in #6
9) take another link
10) press "I"...... already existing inbox-index-file displays fine
11) link to #6 again..... core displays the copy already in the cache
12) view massage #7
13) view massage #8
14) view massage #9
15) view massage #10
16) link to a page
17) load 20 images on this page
18) image 1 is added to cache index
19) image 2 is added to cache index
20) image 3 is added to cache index
21) image 4 is added to cache index
22) image 5 is added to cache index
23) image 6 is added to cache index
24) image 7 is added to cache index
25) image 8 is added to cache index
26) image 9 is added to cache index
27) image 10 is added to cache index
18) image 11 is added to cache index
29) image 12 is added to cache index
30) image 13 is added to cache index
31) image 14 is added to cache index
32) image 15 is added to cache index
33) image 16 is added to cache index
34) image 17 is added to cache index
35) image 18 is added to cache index
36) image 19 is added to cache index
37) image 20 is added to cache index
|
|
|
|
|
256) link to a page
257) link to another page
258) link to one more page
258) press "I"...... since item #1 (the inbox), has been deleted
     from the cache...... tell insight to create a new one
259) link to #1 ..... since it's HTM also gone from the cache.... core
     tells insight to create a new HTM conversion of the CNM
260) link to ">>" button for #2.... since #2 is also gone.... core
     tells insight to create a new HTM conversion of the CNM
261) press "I".... newly created index is still there so it is displayed
     without re-createing it.
262) link to #10..... it didn't get deleted from the cache yet so the
     already existing HTM in the cache dir is displayed.
263) ">>" for #11.... ditto
264) press "I"..... still there... display it
265) link to #4.... it's HTM is gone now.... tell insight to re-create it
________________________

SO,
Maybe it's not a "fullmoon" that does it.
Maybe it's a "full-cache".

All of the above still applies even if we have "Cache2Temp Yes"
Because "refference to" the converted HTM files and "control of" whether
or not the delete them is still being done by the section of core.exe
which manages the files in the cache directory.
This also applies to those `local files' which were "cached" in the
`temp dir' instead of in the `cache dir'.



But then again..... I might just be "Full-of-it". ;-)


-- 
 Glenn
 http://arachne.cz/
 http://freedos-32.sourceforge.net/
 http://www.delorie.com/listserv/mime/
 http://www.angelfire.com/id/glenndoom/download.htm

Reply via email to