Andrew Hodgkinson
authored
Got the deferred reformatter working properly. It doesn't do that 'OK, the page is fetched and reformatted, but just to annoy you, I'm going to wait 5 seconds and then suddenly reformat the whole thing again' trick anymore. The fetcher was calling the reformatter in a delayed form even when the reformatter was already running, so it would carry on past the reformat point or from below what had become and invalidated line, and some time later, get back to the delayed reformat. Now, reformatting is only delayed by the fetcher when the reformatter is not running. In practice this means body text reformats as it fetches, but large tables will show delayed reformatting - which was exactly the intended behaviour of the feature when it was originally thought of.
fetch_token_data_address removed; it was only needed in two places,
both of which already knew when to read tp->text and when to ignore
it. Its functionality is duplicated in an 'if' involving reformat_istext,
anyway.
!Run[D] files taken back to requiring HTTP 0.33, since 0.36 introduces
many weird and wonderful problems.
Typo in Messages files, 'All current images (sic.) fetches finished' -
'images' is now 'image'.
Shift+Click saving - you could save to an application. No problem. But
the equivalent (just clicking on a link that led to an unknown datatype
and getting the save dialogue that way) didn't work. It does now.
Another problem was saving to an application that didn't support the
datatype - oops, the dialogue would close but the fetch would sit there
waiting to be told where to save. It doesn't close now (as expected).
NB, doing several simultaneous fetches to a text editor may have problems
as the editors are too clever for their own good. Despite receiving
DataLoad messages for <Wimp$Scrap> for files of different types, sizes
and datestamps, the editors can decide it's still the same file and:
Zap - Hats off, it gets it right, almost. You do get warned 'Multiple
copies - one on disc is newer' as everything after the first
text loads, but they do load, and in separate windows.
StrongED - Does not load the subsequent files, so the browser gives 'Data
transfer failed' errors and opens up Scrap. Turning off 'Don't
load same file twice' fixes it - each file is loaded in a new
window with no warnings. At least in the first case, you don't
lose data, since the files are kept in Scrap.
Edit - Each time it loads the file, it *replaces* the other one in
memory, using the same window for each. This is the worst
behaviour as it isn't configurable (well, I don't know of a way
to change it...) and results in data loss as successive texts
get trounced by the new data.
I can't see how I can fix this in the browser as it's basically silly
behaviour on behalf of the editors. Other applications which don't try
to work out if it's a new file or not are fine!
When conducting image fetches, proxying is allowed unless reloading.
When conducting page fetches, proxying was never allowed - so web cache
stuff would have been, er, interesting. It now sets X-NoProxy: in the
request header when reloading, but otherwise this is not included.
AnimSpeed is, at last, independent of browser poll speed. They used to
be tied together. Guess how the animation code used to work ;-)
'Can't handle this datatype' - deprecated now that save dialogues can be
popped up. The 'can't save objects in full screen mode' error would never
be shown due to a bug, anyway; this now replaces 'can't handle', which
has been removed from all Messages files.
RefoWait, RefoHang and RefoTime moved from Controls back to Choices.
Trying to get rid of strlen in the reformatter - it can get very slow
(e.g. strlen of 8K chunks of text, or if a 330K text file is transferred
from a text editor straight to the browser, strlen of a 330K string...).
There will be unfinished bits of code in the reformatter that may seem
unnecessary - they've just not been plugged in yet (since they don't
actually work). Don't remove them!