I'm sure there is a .dll to do that, but it would involve a callback, I'm sure.
I have resolved the situation in a different way, without rebol.
How did you do it Giuseppe?
Hi Greg, I had to download the elements of a web table and put it inside a database. Excel did the job for me. I have learnt it could query a multipage table and write the columns on the current sheed. I was able to finish a multy day job in just 5 minutes.
In the past years, someone gave me a ULTRAEDIT wordfile for REBOL.I don't' remember if version 2 or 3. I have lost the file but I don't remember the person. Could someone help ?
Might have been me. I'm signing off right now, but ping me and I'll send you my UE REBOL stuff.
might be me too... but mine is highly customized... not very usefull anymore.
(for someone other than me)
Is there a good reason for ROUND to return a decimal! instead of an integer! like it does in Rebol2?
Rebol3: >> round 2.3 == 2.0
Rebol2 >> round 2.3 == 2
Help text says "ROUND returns the nearest integer" but it doesn't always return an integer: May be he thought that its better to keep the datatype of the return value same: >> round/to 1.987 0.37 == 1.85
There's no mention of the return type in the R3 version of ROUND docstrings.
It is on R2.
Using /TO changes the result type, but with out it ROUND always returns an integer, correct? If so, the help string for /TO implicitly covers it I think.
But, for Doc, I don't know a good reason to change it. Do you have one?
Correct, returns integer for all other refinements.
As you know, one of the reasons to return an integer was for use with loops.
@Gregg I don't understand the rationale of Rebol3 returning a decimal! instead of integer!. Qingtian implemented it in Red copying R3 semantics, but I am about to change it to have R2's semantics, but I want first, to understand the reason for R3's behavior.
Ah, I see. I don't know why the change was made either, except that they made it a native from a mezz. Maybe it was just an implementation detail?
It looks too obvious to be a bug, so I guess it was planned. I still don't get why as it makes it impractical for the common use-case.
R3 changed to support non-integer values for loops, so the result is usable, but I don't remember why that change was made.