Uhh, wut?

Summary Fact: CONVERT works extremely fast on large items if COMPILED with
(O)

however you have to jump through the hoop that an O Compiled program
will only run as optimised if called from an optimised program. It falls
back to standard Basic if called from a standard BASIC compile.

Simple solution in a program not optimised is EXECUTE COPY it to
WINDOWS and COPY it back.

Summary Fact: CONVERT works extremely fast on large items if COMPILED
with
(O)

No argument. That's what it's for.

however you have to jump through the hoop that an O Compiled program
will only run as optimised if called from an optimised program. It falls
back to standard Basic if called from a standard BASIC compile.

What you're describing is what I explain in page 3 of the following
blog:
nospamNebula-RnD.com/blog/tech/mv/2008/04/d3flash1.html


Simple solution in a program not optimised is EXECUTE COPY it to
WINDOWS and COPY it back.

Peter, you're confusing movement of data from OS into D3 with the
processing of the data after it's in D3. FlashBASIC has nothing to do
with a COPY command because COPY is done outside of BASIC. The speed
of copy from Windows to D3 or back will be exactly the same because
you're dealing with the file tier, not BASIC workspace. Your
performance is attained when you're doing string operations on the
dynamic array because now you're operating in a single block of fast
memory with C++ rather than in paged frame space where links need to
be chased by assembler code.

Now, if you are doing the following:
OPEN 'C:/path' TO FV ELSE STOP
READ INFO FROM FV,'filename.ext' ELSE STOP
I could be wrong but I believe the performance of that READ will be
better with Flashed code than with non-flashed because as stated above
INFO is in memory and you're not grabbing a new frame of overflow
every 4k or so. But again, this is not related to this:
EXECUTE "COPY C:/path file.ext": at (no spam) AM:"(MYFILE"

Part 2 of the above blog discusses some nuances of %functions which I
mentioned earlier:
nospamNebula-RnD.com/blog/tech/mv/d3/2009/06/d3flash2.html

HTH
T

Hi Tony
It is you that is confused not I.  My solution works perfectly because of
the reasons given.  End of story.  The simple fact is that the COPY is using
Flashed code to do the translate after it has moved the data block which an
unflashed master program cannot do.
Peter McMurray

It seems to me that people do not read very carefully.

Hi Tony
It is you that is confused not I. My solution works perfectly because of
the reasons given. End of story. The simple fact is that the COPY is using
Flashed code to do the translate after it has moved the data block which
an
unflashed master program cannot do.
Peter McMurray

It seems to me that people do not read very carefully.

Feel free to believe that the code used to do the conversion in the COPY
DOS: routine is different to that called by an optimised FlashBasic program
if that makes you happy.

EXECUTE "COPY DOS:D:/ ":RECKEY:" (O)"

The compile method should have no bearing over executed or chained
programs as they are outside the scope of current code.

Well, he is correct that flashed code must call to flashed code and
unflashed must call to unflashed. See page 3 of the mentioned blog.

EXECUTE "COPY DOS:D:/ ":RECKEY:" (O)"

The compile method should have no bearing over executed or chained
programs as they are outside the scope of current code.

Well, he is correct that flashed code must call to flashed code and
unflashed must call to unflashed. See page 3 of the mentioned blog.

This is an "execute" not a "call".
"Execute" just passes control to another program and works regardles
of program type, be it Basic, Proc, Access or a non-PICK program as in
EXECUTE CHAR(255):"sh"

Lucian

"Peter McMurray" wrote:
Feel free to believe that the code used to do the conversion in the COPY
DOS: routine is different to that called by an optimised FlashBasic
program
if that makes you happy.

I don't suppose you recall that I was QA Manager and later Product
Manager for the software that we're discussing? I don't make this
crap up, I do have some clue.

The OSFI driver is not related to the compilation method of code
invoking it. A simple proof is that you can use all OSFI functions
from TCL, entirely outside of BASIC.

Please feel free to contact your support provider or TL Support
directly, and ask them to explain how it works. Until then, please
stop insisting that you know the internals of this stuff when you just
discovered it a couple days ago! C'mon, how rational is that?

T