I am in the last stages of a programming change, and I am getting
unexpected results. I do not know why yet.

Part of the awkwardness is that the values that I want to check
are long multiline strings. These do not show well or accurately in
the debugger. The pieces that I am concatenating seem to be correct,
but somehow, the long strings are going pear-shaped. I do not know if
the erroneous results I am getting are due to a bug of mine or an
artefact of VFP's.

What is a good way to interrogate the values of multiline
strings?

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

On Wed, 01 Nov 2006 09:21:21 -0800, Gene Wirchenko <genew (AT) ocis (DOT) net>
wrote:

I have never found a really good way to do this. Some possibilities
are:

Use SUBSTR() in the debugger Watch window.
Use MLINE() in the Watch window.
Write a form that you use only for this purpose, with a single
parameter that is the string. In the command window:
DO FORM xxx WITH cStr
You can put whatever you want on that form - and edit box, code to
display the lengths of each line, etc.

I use the latter technique for looking at arrays, since array display
in the Watch window has been broken for a long time now.

Hi Gene,

In the development popup is a bar to open the command window in dockable state.
In this state it is opened in the windows desktop, independent from _SCREEN.

During debugging, while the program is suspended, I open the command window and
type:
_cliptext = the_same_expression_as_in_watch_window<enter>
It is possible to copy this expression right from the watch window.
Then I open some editor, mostly notepad. There I paste the clipboard and can
read all the lines.

Regards
Bernhard Sander

I do something similar but usually MODI FILE JUNK and paste there instead of
notepad. After all, I'm already IN the command window. <g> OTOH, there's
always an empty.txt icon on my desktop for pasting various strings,
stripping formatting, etc.

This is one of those YMMV subjects. What works for you will seem awkward to
someone else who prefers MESSAGEBOX(), etc.

Dan



Bernhard Sander wrote:

Bernhard Sander <fuchs (AT) no (DOT) spam> wrote:

That sounds interesting. Could you please post the code (or more
details at the least)?

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

xposting sucks.... but

mlines() is nice -- but be sure you SET MEMOWIDTH first.
alines() is better to make an array


On Wed, 01 Nov 2006 09:21:21 -0800, Gene Wirchenko <genew (AT) ocis (DOT) net> wrote:


--- AntiSpam/harvest ---
Remove X's to send email to me.

Josh Assing <XjoshX (AT) jassing (DOT) com> wrote:

To two related newsgroups? Come now.

Top-posting is worse.

Unless I get a response to my latest post (new thread), I will be
storing line-by-line, so I will not have to parse the strings.
Fortunately, it will not be too much rewriting, but ah, the time that
has been wasted by this.

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Hi Gene,

I have a special startup prog. With it I start the program in the IDE. There I
define a global variable _devmode and set it to .T.
In the main program I redefine the variable if it does not exist. In that case,
I leave it at .F.
In the main program there is a line CLEAR ALL. It would destroy the _devmode
variable. Work around: CLEAR ALL does not clear the system variable _pdparms.
This I use as intemediate store for _devmode:
*--
PUBLIC _pdparms(1)
_pdparms(1) = iif(type("_devmode") = "U" , .F., .T.)
CLEAR ALL
PUBLIC _devmode
_devmode = _pdparms(1)
*--
In the definition of the menu(s) (I only have hand coded menus), if _devmode is
true, I extend the menu with whatever I need in developement mode.
One pad simply calls SUSPEND
Another pad calls RESUME
Another pad opens the command window
With another pad I can activate the (normally not visible) screen, so that I can
read the output from commands of the command window and it does not overwrite
some form.
Another pad calls the cleanup routine of my program
This is very useful, if I cancel program execution from the debugger. At this
point, all the forms and menus continue to live as they where active before the
cancel. With this pad I savely return to the IDE.

To activate the command window in dockable state I use a little program:
*--
WDOCKABLE("command", .T.)
ACTIVATE WINDOW command
*--

To activate the screen:
*--
_screen.Visible = .T.
ACTIVATE SCREEN
*--

Regards
Bernhard Sander