Topic: Strings & Filespecs (1 of 22), Read 51 times, 1 File Attachment
Conf: VEDIT Macro Language Support
From: Ian Binnie
Date: Tuesday, June 15, 2004 09:40 AM

I have written a macro which is supposed to rename files saved from an email program based on the Subject:.

By and large the macro works (it is attached) but I have encountered a few problems:-

1. After some attempts to generate filenames on the fly (e.g. @(26)|(FILE_EXT) and/or delimit with quotes I have come to the conclusion that the only workable option is to generate full pathnames in a text register.

This could be explained better in documentation/help files.

2. File_Rename() includes the following :-
"Rename the file 'oldfile' to 'newfile'. Similar to using the DOS "REN" command."

This is confusing (and wrong) as the Windows help states:-
"REN [drive:][path]filename1 filename2."
Note that you cannot specify a new drive or path for your destination file."

Vedit REQUIRES a full path for the 'newfile'. (I had to determine this by trial & error.)

3. While debugging the macro I found that displaying text registers with \t (or any '\') is confusing.
\t is converted to tab, other '\' just seem to be consumed. (there are a couple of Dialog_Input_1 commands in the attached)

\t & \n are documented for strings, but not other '\'. I assume I could convert to '\\', but have not tested this and it is not documented.

4. When running under the wildfile macro files containing "Subject: Re: IMPORTANT NOTICE re ASF ELECTRONIC COMMUNICATION" ended up renamed to 'IMPORTANT NOTICE re ASF ELECTRONIC" rather than "IMPORTANT NOTICE re ASF ELECTRONIC COMMUNICATION"

I have been unable to debug this to date due to some of the difficulties above, but my construction of filenames seems to be OK.


PS I do understand File_Rename() is only there because it is used in the Vedit installation macro, but it is a very handy command.

 
EMAILSUBJECT.VDM (3KB)

 


Topic: Re: Strings & Filespecs (2 of 22), Read 44 times
Conf: VEDIT Macro Language Support
From: Christian Ziemski
Date: Tuesday, June 15, 2004 02:21 PM

On Tue, 15 Jun 2004 09:40:00 -0400, Ian Binnie wrote:

>I have written a macro which is supposed to rename files saved from
>an email program based on the Subject:.

Good idea!


>[ ...] but I have encountered a few problems:-
>
>1. After some attempts to generate filenames on the fly (e.g. @(26)|(FILE_EXT)
>and/or delimit with quotes I have come to the conclusion that the only workable
>option is to generate full pathnames in a text register.

Where are your problems with that? I often use on-the-fly filenames.


>2. File_Rename() includes the following :-
>"Rename the file 'oldfile' to 'newfile'. Similar to using the DOS "REN"
>command."
>
>This is confusing (and wrong) as the Windows help states:-
>"REN [drive:][path]filename1 filename2."
>Note that you cannot specify a new drive or path for your destination file."
>
>Vedit REQUIRES a full path for the 'newfile'. (I had to determine this by trial
>& error.)

Not exactly.

VEDIT's online help additionally states for File_Rename:
"If 'newfile' is on a different drive or directory from 'oldfile', the
file is moved to the new location."

And that is done.
In the case that 'newfile' has no path given, VEDIT uses the current
directory (CHDIR).

And:
"File_Rename() and File_Move() are different names for the same
command."

Perhaps Windows' command "MOVE" should be also mentioned.



>3. While debugging the macro I found that displaying text registers with \t (or
>any '\') is confusing.
>\t is converted to tab, other '\' just seem to be consumed. (there are a couple
>of Dialog_Input_1 commands in the attached)

IIRC the backslashes are used by windows (like \t).
And VEDIT uses Windows functions (here and there... ;-)


>\t & \n are documented for strings, but not other '\'. I assume I could convert
>to '\\', but have not tested this and it is not documented.

Yes, doubling the backslash makes one real one.

Have a look at the sentences

" .\ Remove the special meaning of "\" in text items.
Useful when "\" is part of the text, e.g. in pathnames. "

in the online help for Dialog_Input_1().
That option should help in many cases.


BTW:
File_Rename(@(28),@(27)) could be written shorter:
File_Rename(@28,@27)


Christian

 


Topic: Re: Strings & Filespecs (3 of 22), Read 44 times
Conf: VEDIT Macro Language Support
From: Ian Binnie
Date: Tuesday, June 15, 2004 08:43 PM

On 6/15/2004 2:21:21 PM, Christian Ziemski wrote:
>On Tue, 15 Jun 2004 09:40:00 -0400, Ian
>Binnie wrote:
>
>>[ ...] but I have encountered a few problems:-
>>
>>1. After some attempts to generate filenames on the fly (e.g. @(26)|(FILE_EXT)
>>and/or delimit with quotes I have come to the conclusion that the only workable
>>option is to generate full pathnames in a text register.
>
>Where are your problems with that? I
>often use on-the-fly filenames.

When I did this I lost several files, and found that they had been moved to the vedit\user-mac directory with incomplete names. I assumed this was because the originals were in E:\test and the tabs were being interpreted.
>
>>2. File_Rename() includes the following :-
>>"Rename the file 'oldfile' to 'newfile'. Similar to using the DOS "REN"
>>command."
>>
>>This is confusing (and wrong) as the Windows help states:-
>>"REN [drive:][path]filename1 filename2."
>>Note that you cannot specify a new drive or path for your destination file."
>>
>>Vedit REQUIRES a full path for the 'newfile'. (I had to determine this by trial
>>& error.)
>
>Not exactly.
>
>And that is done.
>In the case that 'newfile' has no path
>given, VEDIT uses the current
>directory (CHDIR).
>
True, but this is different from REN, where the path is based on the source file.

>Have a look at the sentences
>
>" .\ Remove the special meaning of "\"
>in text items.
>Useful when "\" is part of the text,
>e.g. in pathnames. "
>
>in the online help for Dialog_Input_1().
>That option should help in many cases.
>
Thanks, I had missed this.

 


Topic: Re: Strings & Filespecs (4 of 22), Read 48 times
Conf: VEDIT Macro Language Support
From: Ted Green
Date: Tuesday, June 15, 2004 11:08 PM

At 08:44 PM 6/15/2004, you wrote:
>When I did this I lost several files, and found that they had been moved to the vedit\user-mac directory with incomplete names. I assumed this was because the originals were in E:\test and the tabs were being interpreted.

Ian:

None of the file handling commands would treat "\t..." as a tab. Only the Dialog_Input_1() command has that characteristic.

>>>2. File_Rename() includes the following :-
>>>"Rename the file 'oldfile' to 'newfile'. Similar to using the DOS "REN"
>>>command."
>>>
>>>This is confusing (and wrong) as the Windows help states:-
>>>"REN [drive:][path]filename1 filename2."
>>>Note that you cannot specify a new drive or path for your destination file."

I guess that depends upon how you interpret "Similar to"; I don't say "exactly like". :-)

>>>Vedit REQUIRES a full path for the 'newfile'.
>>
>>Not exactly.
>>
>>In the case that 'newfile' has no path
>>given, VEDIT uses the current directory (CHDIR).

In general it is a good idea to use full pathnames to avoid surprises.

BTW -
Whoever the DOS 2.0 designer was that decided to use "\" in pathnames instead of the already-standard "/" as in UNIX should be strangled. That really is the source of all this confusion and why command like Dialog_Input_1() are more complex than they should be.

BTW2 -
In VEDIT macros, you can use "/" instead of "\" in pathnames; VEDIT will internally correct it. I did this so that the same macros could be used with our previous SCO-UNIX and QNX versions (now discontinued).

Christian - thank you for answering so many messages lately and especially this one, as I didn't originally understand what Ian was asking. :-))

Ted.


Chris
-------------------------------------------------------------------------
Chris Stachnik (chris@...) Greenview Data, Inc.
Web: http://www.... PO Box 1586, Ann Arbor, MI 48106
Tel: (734) 996-1300 Fax: (734) 996-1308 VEDIT - Text/Data/Binary Editor

 


Topic: Re: Strings & Filespecs (5 of 22), Read 51 times
Conf: VEDIT Macro Language Support
From: Ian Binnie
Date: Wednesday, June 16, 2004 09:15 AM

On 6/15/2004 11:08:06 PM, Ted Green wrote:
>None of the file handling
>commands would treat "\t..."
>as a tab. Only the
>Dialog_Input_1() command has
>that characteristic.
Thanks, Christian the master of Dialog_Input_1 helped me in that respect.

>I guess that depends upon how
>you interpret "Similar to"; I
>don't say "exactly like". :-)

>In general it is a good idea
>to use full pathnames to avoid
>surprises.

By the time of my post I understood this.
My comments were a documentation of my confusion, and intended as feedback - possibly to improve Vedit documentation to help others in the future.

>BTW -
>Whoever the DOS 2.0 designer
>was that decided to use "\" in
>pathnames instead of the
>already-standard "/" as in
>UNIX should be strangled. That
>really is the source of all
>this confusion and why command
>like Dialog_Input_1() are more
>complex than they should be.

I could not agree more. Strangling would be too good!!


>BTW2 -
>In VEDIT macros, you can use
>"/" instead of "\" in
>pathnames; VEDIT will
>internally correct it. I did
>this so that the same macros
>could be used with our
>previous SCO-UNIX and QNX
>versions (now discontinued).

I am a former user of these versions.
>
>Christian - thank you for
>answering so many messages
>lately and especially this
>one, as I didn't originally
>understand what Ian was
>asking. :-))

I agree.
My post was an attempt to get some help from other Vedit users, and Christian certainly helped.

I still have the problem with wildfile.
As a result of Christian's feedback on Dialog_Input_1 my diagnostics now indicate that the resultant problems I have with this macro (which works perfectly if run directly on a single file) are not with File_Rename, but are a truncation of the name in a text register.

The displayed name is truncated before calling File_Rename when run from wildfile. I am at a loss why.

I have even changed text registers but can see to conflict.


-----------------------------
>------------------------------
>-------------
>Chris Stachnik
>(chris@...)
>Greenview Data, Inc.
>Web: http://www....
>PO Box 1586, Ann Arbor, MI
>48106
>Tel: (734) 996-1300 Fax: (734)
>996-1308 VEDIT -
>Text/Data/Binary Editor
>

 


Topic: Re: Strings & Filespecs (6 of 22), Read 51 times
Conf: VEDIT Macro Language Support
From: Christian Ziemski
Date: Wednesday, June 16, 2004 02:12 PM

On Wed, 16 Jun 2004 09:15:00 -0400, Ian Binnie wrote:

>I still have the problem with wildfile.
>As a result of Christian's feedback on Dialog_Input_1 my diagnostics now
>indicate that the resultant problems I have with this macro (which works
>perfectly if run directly on a single file) are not with File_Rename, but are a
>truncation of the name in a text register.
>
>The displayed name is truncated before calling File_Rename when run from
>wildfile. I am at a loss why.
>
>I have even changed text registers but can see to conflict.

Let us know some more details and the current version of your macro
and we may be able to help.


Christian - MoD (thanks Ian ;-)

 


Topic: Re: Strings & Filespecs (7 of 22), Read 52 times, 1 File Attachment
Conf: VEDIT Macro Language Support
From: Ian Binnie
Date: Thursday, June 17, 2004 02:16 AM

On 6/16/2004 2:12:51 PM, Christian Ziemski wrote:
>On Wed, 16 Jun 2004 09:15:00 -0400, Ian
>Binnie wrote:
>
>>I still have the problem with wildfile.
>>As a result of Christian's feedback on Dialog_Input_1 my diagnostics now
>>indicate that the resultant problems I have with this macro (which works
>>perfectly if run directly on a single file) are not with File_Rename, but are a
>>truncation of the name in a text register.
>>
>>The displayed name is truncated before calling File_Rename when run from
>>wildfile. I am at a loss why.
>>
>>I have even changed text registers but can see to conflict.
>
>Let us know some more details and the
>current version of your macro
>and we may be able to help.
>
>
Christian,

I am running WILDFILE.VDM: 22-October-2003
using VEDIT (32-Bit) Ver. 6.12.1 05/24/04

I have absolved Wildfile, as the problem also occurred when I made a batch file to autoexecute the macro on each file.

This is strange as it works perfectly if run in interactive mode.

I did some more experimenting, and finally resolved the issue by deleting my eml.cft file.

I made a new eml.cft file (with default settings - except for syntax highlighting) and wildfile worked, but when I set Enable word wrap (display) it broke again.

The resultant changes in eml.cft are:-
Config( D_DSP_WRAP, 1,LOCAL )
Config( D_E_NEWL_D_C, 2,LOCAL )

I am still at a loss why this should make a difference, but it does explain why the truncation is always at a word boundary.

The latest version of the macro is attached.
What I thought would be a simple task to modify an existing macro has taken days.

 
EMAILSUBJECT(1).VDM (4KB)

 


Topic: Re: Strings & Filespecs (8 of 22), Read 54 times
Conf: VEDIT Macro Language Support
From: Christian Ziemski
Date: Thursday, June 17, 2004 08:08 AM

On 6/17/2004 2:16:59 AM, Ian Binnie wrote:

>I did some more experimenting, and finally resolved the >issue by deleting my eml.cft file.
>
>I made a new eml.cft file (with default settings - except >for syntax highlighting) and wildfile worked, but
>when I set Enable word wrap (display) it broke again.
>
>The resultant changes in eml.cft are:-
>Config( D_DSP_WRAP, 1,LOCAL )
>Config( D_E_NEWL_D_C, 2,LOCAL )
>
>I am still at a loss why this should make a difference, but >it does explain why the truncation is always at a word
boundary.


Ian:

That's it!

In your macro you are using the command
Reg_Copy_Block(65,Cur_Pos,EOL_Pos) // copy Subject to outreg

And that one truncates the subject if WordWrap is on and had wrapped the subject line (even if only in "display").

So it seems that EoL_Pos always only finds the visible end-of-line and not the real end.

That may be a bug or a feature...
If it's a feature it should be documented!

The easiest way to workaround this is to disable WordWrapping in the beginning of your macro with the above Config() commands (set to 0 of course).

Christian

 


Topic: Re: Strings & Filespecs (9 of 22), Read 54 times
Conf: VEDIT Macro Language Support
From: Ted Green
Date: Thursday, June 17, 2004 09:12 AM

At 08:09 AM 6/17/2004, you wrote:

>So it seems that EoL_Pos always only finds the visible end-of-line and not the real end.
>
>That may be a bug or a feature...
>If it's a feature it should be documented!

Christian:

Thank you for figuring this one out!

I will study this some more and determine if it is a bug or a feature. If a feature, I will document it and perhaps implement an option to specify whether it is the position of the real end-of-line or the visible end-of-line.

Ted.

 


Topic: Re: Strings & Filespecs (11 of 22), Read 55 times
Conf: VEDIT Macro Language Support
From: Christian Ziemski
Date: Thursday, June 17, 2004 09:32 AM

On 6/17/2004 9:12:51 AM, Ted Green wrote:
>
>I will study this some more and determine if it is a bug
>or a feature.

The same "problem" applies to Search()!

Search("|>") finds the visible EoL
Search("|N") finds the real EoL.

That MAY be a real problem in macros if wordwrap is enabled...

Christian

 


Topic: Re: Strings & Filespecs (14 of 22), Read 55 times
Conf: VEDIT Macro Language Support
From: Ted Green
Date: Thursday, June 17, 2004 03:02 PM

At 09:32 AM 6/17/2004, you wrote:
>The same "problem" applies to Search()!
>
>Search("|>") finds the visible EoL
>Search("|N") finds the real EoL.
>
>That MAY be a real problem in macros if wordwrap is enabled...

Very interesting!!

Config setting really shouldn't change macro behavior.
(Changing the file-type/record-size is an obvious exception.)

Therefore, I probably should change the code so that word-wrap only applies to Visual Mode functions.

Of course, if you then try to emulate the key with a macro such as Goto_Pos(EOL_Pos), it won't work.

I could let having Config(D_DSP_WRAP) set to the special value of "2" enable word-wrap even in the macro language.

Ted.

 


Topic: Re: Strings & Filespecs (15 of 22), Read 61 times
Conf: VEDIT Macro Language Support
From: Christian Ziemski
Date: Thursday, June 17, 2004 04:43 PM

On Thu, 17 Jun 2004 15:02:00 -0400, Ted Green wrote:

>At 09:32 AM 6/17/2004, you wrote:
>>
>>Search("|>") finds the visible EoL
>>Search("|N") finds the real EoL.
>
>Config setting really shouldn't change macro behavior.
>
>Therefore, I probably should change the code so that word-wrap only
>applies to Visual Mode functions.

Yes, I also think this way.
Especially since it is named {View, Word wrap (*display*)}

>Of course, if you then try to emulate the key with a macro
>such as Goto_Pos(EOL_Pos), it won't work.

Hmmm, not absolutely perfect. But you can't please everyone... ;-)
If that is documented in the "WordWrap" topic in the help it should be
sufficient.

IMHO correct running macros are most important. Hidden effects are
much more dangerous there as in visual mode.

>I could let having Config(D_DSP_WRAP) set to the special value of
>"2" enable word-wrap even in the macro language.

Yes, that would allow macros (e.g. the above emulation) to do what
they want!

VEDIT, the Master of Options ;-)


Christian

 


Topic: Re: Strings & Filespecs (17 of 22), Read 35 times
Conf: VEDIT Macro Language Support
From: Ted Green
Date: Monday, September 06, 2004 02:00 PM

At 03:03 PM 6/17/2004, you wrote:
>At 09:32 AM 6/17/2004, you wrote:
>>The same "problem" applies to Search()!
>>
>>Search("|>") finds the visible EoL
>>Search("|N") finds the real EoL.
>>
>>That MAY be a real problem in macros if wordwrap is enabled...

I tried some coding changes, but they only introduced other problems. Therefore, nothing was changed in 6.13.

I am considering some possibilities for the future.

1. Implement additional pattern matching codes to match
the real BOL/EOL. Perhaps "|^" and "|$" which correspond
to regular expressions.

2. Better yet, I was thinking of a "NOWRAP" option on the
Search() and Replace() commands.

Ted.

 


Topic: Re: Strings & Filespecs (18 of 22), Read 41 times
Conf: VEDIT Macro Language Support
From: Christian Ziemski
Date: Monday, September 06, 2004 03:10 PM

On Mon, 06 Sep 2004 14:00:00 -0400, Ted Green wrote:

>At 03:03 PM 6/17/2004, you wrote:
>>At 09:32 AM 6/17/2004, you wrote:
>>>The same "problem" applies to Search()!
>>>
>>>Search("|>") finds the visible EoL
>>>Search("|N") finds the real EoL.
>>>
>>>That MAY be a real problem in macros if wordwrap is enabled...
>
>I tried some coding changes, but they only introduced other problems.
>Therefore, nothing was changed in 6.13.
>
>I am considering some possibilities for the future.
>
>1. Implement additional pattern matching codes to match
> the real BOL/EOL. Perhaps "|^" and "|$" which correspond
> to regular expressions.
>
>2. Better yet, I was thinking of a "NOWRAP" option on the
> Search() and Replace() commands.


NO-wrapping should be the default IMHO.

Why not create a "WRAP" option:

That WRAP option may be checked [x] by default when using the
Search/Replace dialog (and word wrapping is enabled) since here the
wrapped lines with their virtual EOLs are visible (but I'm not sure if
good)
but the option should *not* be set by default in macros!!

If in doubt the option should be unset (=> no wrap) per default in
both cases.


Christian

 


Topic: Re: Strings & Filespecs (19 of 22), Read 45 times
Conf: VEDIT Macro Language Support
From: Ted Green
Date: Monday, September 06, 2004 04:03 PM

At 03:10 PM 9/6/2004, you wrote:
>NO-wrapping should be the default IMHO.
>
>Why not create a "WRAP" option:

OK, I was thinking either a "NOWRAP" or a "WRAP" option. It is surprising complex to determine how best to do this.

VEDIT internally has 4 critical routines, call them NextLine(), PreviousLine(), AtBOL() and AtEOL(). First I tried changing them to check for word-wrap only in Visual mode and ignore word-wrap in Command mode.

First problem was that any functions internally implemented as Command macros no longer worked in word-wrap. For example, printing no longer wrapped.

Then I extended it to check for word-wrap if the macro was run from Visual mode. However this would cause macros to behave differently depending upon how they were invoked.

I tried other variations, but in all cases the new problems were worse than the original problem.

Back to NOWRAP or WRAP.

Should the Line() and Type() commands check for word-wrap? I think so; they currently do. (And they must for internal macros.) Therefore, they might need a NOWRAP option. I don't want to have both WRAP and NOWRAP options.

Since this is so complex, the first simple step might be to implement
new "|^" and "|&" search patterns which check for word-wrap.

Ted.

 


Topic: Re: Strings & Filespecs (20 of 22), Read 47 times
Conf: VEDIT Macro Language Support
From: Ian Binnie
Date: Monday, September 06, 2004 10:10 PM

On 9/6/2004 4:03:10 PM, Ted Green wrote:
>At 03:10 PM 9/6/2004, you
>wrote:
>>NO-wrapping should be the default IMHO.
>>
>>Why not create a "WRAP" option:
>
>OK, I was thinking either a
>"NOWRAP" or a "WRAP" option.
>It is surprising complex to
>determine how best to do this.
>
>VEDIT internally has 4
>critical routines, call them
>NextLine(), PreviousLine(),
>AtBOL() and AtEOL(). First I
>tried changing them to check
>for word-wrap only in Visual
>mode and ignore word-wrap in
>Command mode.
>
>First problem was that any
>functions internally
>implemented as Command macros
>no longer worked in word-wrap.
>For example, printing no
>longer wrapped.
>
>Then I extended it to check
>for word-wrap if the macro was
>run from Visual mode. However
>this would cause macros to
>behave differently depending
>upon how they were invoked.
>
>I tried other variations, but
>in all cases the new problems
>were worse than the original
>problem.
>
>Back to NOWRAP or WRAP.
>
>Should the Line() and Type()
>commands check for word-wrap?
>I think so; they currently do.
>(And they must for internal
>macros.) Therefore, they might
>need a NOWRAP option. I don't
>want to have both WRAP and
>NOWRAP options.
>
>Since this is so complex, the
>first simple step might be to
>implement
>new "|^" and "|&" search
>patterns which check for
>word-wrap.
>
>Ted.

Since Christian pointed out the problem I include the following in my macros which may be affected:-

Config( D_DSP_WRAP, 0,LOCAL ) // Needed to capture end of long lines

If I was really serious I would save & restore D_DSP_WRAP, but this is not needed in most of my bulk macros.

This is far easier than putting a NOWRAP in all affected commands.

The most important thing is to document the behavior - including the help file.

The new search patterns could be handy, but really only of use if the macro is dependent on what is displayed on screen.

 


Topic: Re: Strings & Filespecs (21 of 22), Read 47 times
Conf: VEDIT Macro Language Support
From: Ted Green
Date: Monday, September 06, 2004 11:49 PM

I just posted a newer preliminary VEDIT+ 6.13 dated 09/07/2004.

Whenever a new buffer is opened, or an existing buffer is closed, VEDIT now turns off Config(D_DSP_WRAP). Hopefully this will reduce problems. For example, if you open a temporary buffer to manipulate some text, you can now be sure that display-word-wrap is off. Previously if the current buffer had word-wrap on, and you opened a temp buffer, it might have started up with word-wrap on too.

Note that the file-open configuration can still enable display-word-wrap for specific file or file-types.

Ted.




Ted.
-------------------------------------------------------------------------
Ted Green (ted@...) Greenview Data, Inc.
Web: www.... Fax: 734-996-1308 PO Box 1586, Ann Arbor, MI 48106
Tel: (734) 996-1300 Desk: 734-369-3550 VEDIT - Text/Data/Binary Editor
-------------------------------------------------------------------------
www.SpamStopsHere.com ranked #1 in accuracy by Network Computing Magazine

 


Topic: Re: Strings & Filespecs (22 of 22), Read 44 times
Conf: VEDIT Macro Language Support
From: Pauli Lindgren
Date: Wednesday, September 08, 2004 01:13 PM

On 9/6/2004 4:03:10 PM, Ted Green wrote:
>
>Then I extended it to check for word-wrap if the macro was
>run from Visual mode. However this would cause macros to
>behave differently depending upon how they were invoked.

Indeed, it is not good idea if a macro works differently depending on how they were invoked.
Same macro code should always do the same thing when executed on the same file. The width of a window should not change the effect of macro (unless the macro was meant to perform some visual operations).

>Should the Line() and Type() commands check for word-wrap?
>I think so; they currently do. (And they must for internal
>macros.) Therefore, they might need a NOWRAP option.

I think there should be different commands for visual end of line and physical end of line operations.

>Since this is so complex, the first simple step might be to
>implement new "|^" and "|&" search
>patterns which check for word-wrap.

Since visual EOL and physical EOL are two different things, they need different pattern matching codes.

In addition, two different internal values are needed instead of single EOL_pos. IMHO, it is logical that EOL_pos refers to the physical newline character. Some other variable name would be needed for visual end of line (VEOL_pos?).

--
Pauli

 


Topic: Re: Strings & Filespecs (10 of 22), Read 54 times
Conf: VEDIT Macro Language Support
From: Ian Binnie
Date: Thursday, June 17, 2004 09:23 AM

On 6/17/2004 8:08:41 AM, Christian Ziemski wrote:
>On 6/17/2004 2:16:59 AM, Ian Binnie
>wrote:
>
>In your macro you are using the command
>Reg_Copy_Block(65,Cur_Pos,EOL_Pos) //
>copy Subject to outreg
>
>And that one truncates the subject if
>WordWrap is on and had wrapped the
>subject line (even if only in
>"display").
>
>So it seems that EoL_Pos always only
>finds the visible end-of-line and not
>the real end.
>
>That may be a bug or a feature...
>If it's a feature it should be
>documented!
>
>The easiest way to workaround this is to
>disable WordWrapping in the beginning of
>your macro with the above Config()
>commands (set to 0 of course).
>
Christian,

I agree that this is plausible, and I will test further.

There is more to this, as the Subject: lines never wrap when I view files - possibly the best option would be to disable all customisation in macros - I do not see that this can be done easily.

I look forward to the official explanation of this feature.

As an aside I have been thinking about another activity of mine - implementing a C++ class to emulate a subset of Vedit (ultimately a lost cause).

For the past 7 years I have written few real programs (i.e. C or C++) because I find that a combination of Excel VBA and Vedit macros lets me solve most problems far quicker.

I have learnt that Microsoft's Object model is imperfect, arbitrary and inconsistent, but have always felt I could rely on Vedit without having to worry about "features".

 


Topic: Re: Strings & Filespecs (12 of 22), Read 57 times
Conf: VEDIT Macro Language Support
From: Christian Ziemski
Date: Thursday, June 17, 2004 09:40 AM

On 6/17/2004 9:23:35 AM, Ian Binnie wrote:
>I agree that this is plausible, and I will test further.
>
>There is more to this, as the Subject:
>lines never wrap when I view files -

That has been my problem too at first.

Then I found out that {Config, Word Processing, Right margin} was set differently in my cft files.

For example .txt files (I tested your macro with) have RightMargin set to 70 here.
My VEDIT window is far bigger and so I never see the wrap. But if run via macro, perhaps minimized, that may fire...

That is just a guess, but I think that may have to do with it.

Christian

 


Topic: Re: Strings & Filespecs (13 of 22), Read 56 times
Conf: VEDIT Macro Language Support
From: Christian Ziemski
Date: Thursday, June 17, 2004 09:58 AM

Ooops,

I wrote a bit nonsense:

>Then I found out that {Config, Word Processing, Right margin}
>was set differently in my cft files.
>
>For example .txt files have RightMargin set to 70 here.
>
>[ and more ...]

And other files have it set to "0" = "Windows width".

And with that latter configuration it may come to the described problem.

Christian

 


Topic: Re: Strings & Filespecs (16 of 22), Read 46 times
Conf: VEDIT Macro Language Support
From: Peter Rejto
Date: Thursday, June 17, 2004 05:17 PM

On 6/15/2004 11:08:06 PM, Ted Green wrote:

>In general it is a good idea
>to use full pathnames to avoid
>surprises.
>
>BTW -
>Whoever the DOS 2.0 designer
>was that decided to use "\" in
>pathnames instead of the
>already-standard "/" as in
>UNIX should be strangled. That
>really is the source of all
>this confusion and why command
>like Dialog_Input_1() are more
>complex than they should be.
>
>BTW2 -
>In VEDIT macros, you can use
>"/" instead of "\" in
>pathnames; VEDIT will
>internally correct it. I did
>this so that the same macros
>could be used with our
>previous SCO-UNIX and QNX
>versions (now discontinued).
>

Thanks Ted:

This has always been a mystery for me.

-peter.