We recently flash compiled our code in order to cohabitate with DesignBais,
which is flash compiled. Now I am having problems with programs that worked
before. For example, the Accuterm subroutine that finds the path to the My
Documents folder hangs on the input statement.

My biggest grip is with the debugger. In particular, the G for go to line#
and S for display stack commands do not work.

All I did was compile all the programs using the O option. Have I missed
something? Any suggestions on what I can do to improve the situation?

--
Jeff

BTW: D3 7.4.1 on Linux Red Hat Enterprise

"Jeffrey Kaufman" <jkaufman (AT) keydata (DOT) us> wrote

On Mar 22, 10:35 am, "Jeffrey Kaufman" <jkauf... (AT) keydata (DOT) us> wrote:
I doubt that an AccuTerm routine is EVER going to work, because you
aren't using AccuTerm anymore!

However, I would assume you MUST still be using Accuterm, otherwise
you wouldn't be able to get into the debugger anyway (maybe a clumsy
tandem from another line)

As to the state of the FlashBASIC debugger --> it is what it is. You
do loose some "stuff", and things may behve differently when flashed

"Jeffrey Kaufman" wrote:


Jeff - Flash is preferred in a lot of cases, but by no means required.
mv.NET and DesignBais both benefit from flash because they deal with
large strings which are optimized by flash.

As Ross said though, when you're working with mv.NET or with
DesignBais, you're not working with AccuTerm code, and you can't use
the debugger from the GUI anyway, so I'm confused about what's going
on there.

You could re-install MV.NET and uncheck the Flash box. In about 15
minutes that will disable flash for all accounts. No changes to
DesignBais are required. I can't recall any way at the moment to
remove the flashed object from flashed modules without recompiling the
source.

To get MV.NET and DesignBais to run unflashed, even when the flashed
object is in place:
1- Logto your app account (needs to be done in each account)
2- SELECT DICT MVNET.BP
3- SELECT MD WITH A1 VR
4- ED MD
5- .P1 1[R/VR/VR1[FI[P1
6- .P1
7- SELECT DICT DBI
8- Repeat steps 3-6

Now when you compile programs, even if you flash compile them, the
object that's used should be the non-flashed version because your
programs will be called from non-flashed code.


To undo all of this,
- SELECT MD WITH A1 VR1
- ED MD
- .P1 1[R/VR1/VR[FI[P1
- .P1

Of course you could put all of that into macros and just run them once
to enable or disable flash.

HTH
T

I had a lot of terminal emulation problems using flashed code on
Windows, so I "unflashed" those systems.. So far, no problems on
linux, and I do use many Accuterm functions.

I don't believe I use the get document path program on my flashed
customers, but I will be careful if I do.

Of course, you flash compiled the FTBP programs?

Tony and Ross,

Although we are making nice strides with our DesignBais development, we
still need to support the green screen application and will need to do so
for some time to come. That mean using Accuterm and the debugger. I think we
had better unflash the programs for now. Perhaps I can flash only the
programs we are using with DB.

Thanks for your input.
Jeff

"Tony Gravagno" <address.is.in.posts (AT) removethis (DOT) com.invalid> wrote in
message news:66n303ho7uiolpf3brjjejteqoa0u36rbh (AT) 4ax (DOT) com...

Yes I did flash FTBP. I also contacted Pete to see if he had run across this
before. Unfortunately he had not.

<douglas (AT) pickteam (DOT) com> wrote

<douglas (AT) pickteam (DOT) com> wrote
FTPICK transfer from d3/linux to d3/proplus {linux box on their office
lan, actual old-fashioned dial-up modem session to the d3/proplus box}
and it was hanging like the proplus box was failing to send the control
codes to start the transfer. Not worth tracking down what was really wrong,
as this is real 'mummy-ware', but I did notice that as a workaround you
can send a single item at a time using ascii mode and FT instead of
FTPICK. Oh how I love kermit-mode FTPICK!!!

Frank, I've run into that before. Make sure control characters are turned
on.

CONTROL-CHARS ON

"Frank Winans" <fwinans (AT) sbcglobal (DOT) net> wrote

Now I know what Tony means about reporting bugs to RD. How long has flash
been available? Three years? Four years? More? No one has ever reported four
of the six problems I reported yesterday. So what does that mean? 1) very
few use flash, 2) very few use the debugger, 3) very few use Accuterm
uploads and downloads with flash, 4) very few care.

1) None of the Accuterm programs that upload and download (FT), or check for
the path to the My Documents folder were working. After about three hours
working with Pete, we finally resolved the problem, err Pete resolved the
problem. For some unknown reason, when I flash compiled the programs, the
type ahead buffer was turned off. Accuterm uses the type ahead buffer
extensively. I added and execute of TA-ON to my routine.

2) Debugger for flashed programs:
a) The S operator, used to display the contents of the program stack does
not work. RD did not know about this. An action was created.
b) The G operator, used to go to a program line during execution, has been
fixed and works in D3 7.5 (so I was told)
c) The /variable does not work when the variable is a dimensioned array. An
action was created.
d) The break key does not work consistently, sometimes requiring a <cr>. RD
says they cannot reproduce this.

3) Debugger for non-flashed programs:
a) The debugger gets lost and cannot display the line it is executing (when
C is used) if the called subroutine is cataloged in a different file than
the calling program. An action was created.


I was told to either upgrade to 7.5 or re-compile the programs without
flash. Of course upgrading only fixes one of the problems.

What we decided to do is separate the subroutines used with DesignBais from
those for the green screen application, and flash only the DB programs. The
disadvantage of course is that program modifications in those subroutines
have to be made twice. We also have to be careful to use the correct
compiler when compiling programs.

Jeff



"Jeffrey Kaufman" <jkaufman (AT) keydata (DOT) us> wrote