Although this is not new with v7, perhaps it is an opportunity to correct
this behavior.

Select to end-of-line does not include the line termination character(s) in
most cases. It is true for all methods (mouse Shift-drag, keyboard
Shift-End or clip ^!Select EOL), in Notetab Pro but only for clip ^!Select
EOL in Notetab Std. Mouse Shift-drag and keyboard Shift-End does include
line terminations in Notetab Std (left to right but not right to left). The
inconsistency in Notetab Std is confusing and seems unnecessary. Since it
only affects the manual UI, the inconsistency could be removed without much
breakage.

Namste',  Art

Hi Art,

In the version 7, selecting to the end of the line, with or without the EOL is
entirely up to the user, and consistent between NTPro and NTStd. At least as far
as I've tested.

I cannot duplicate any differences.

You click on the begin of the line, the entire line, incl eol, is selected. Both
editions.

Both the mouse and the cursor keys work the same way in Pro and Std. You do have
to press the SHIFT key to make a selection with the keyboard.

Use the mouse or cursor key to drag the selection from the start to the end does
NOT select the EOL character(s).

Use the mopuse or cursor to drag to the start of the next line DOES include the
EOL.

^!Select EOL
does NOT include the EOL

^!Select LINE
DOES include it,

in both, Pro and Std.

What methods have I missed, that are inconsistent?


Cheers,


Eb

--- In notetab@yahoogroups.com, Art Kocsis <artkns@...> wrote:
>
> Although this is not new with v7, perhaps it is an opportunity to correct
> this behavior.
>
> Select to end-of-line does not include the line termination character(s) in
> most cases. It is true for all methods (mouse Shift-drag, keyboard
> Shift-End or clip ^!Select EOL), in Notetab Pro but only for clip ^!Select
> EOL in Notetab Std. Mouse Shift-drag and keyboard Shift-End does include
> line terminations in Notetab Std (left to right but not right to left). The
> inconsistency in Notetab Std is confusing and seems unnecessary. Since it
> only affects the manual UI, the inconsistency could be removed without much
> breakage.
>
> Namste',  Art
>

NoteTab Pro should be a proper superset of NoteTab Std.
NTP should include all of the features/capabilities of NTB
and exhibit identical behaviors for those capabilities that
they have in common. Unfortunately that is not now the case.
Without a pre-release version of Notetab Std to test, it is
impossible to determine which differences still remain.

In particular, a *.url file opens in NTP7b5 as a *.txt file, as it
should. However,  NTP4, NTB5, NTB6 opens these files as
bastardized htm files which contains the url but none of the
rest of the source content. How will NTB v7 handle these files?

In NTB 5.8/fv, the "^" RegEx operator seems to have a random
behavior. (I had to revert back to NTB v5.8/fv because 6.2/fv had
too many memory buffer bugs and clips were corrupting my files.)
Sometimes NTB would act correctly and restrict the pattern to
search from BOL. Other times it would start from anywhere. IIRC,
Flo(?) at one time made the comment that in NTP (6?), a "^" search
pattern could always start anyplace in the line. I think that violates
the entire purpose of the "^" operator but it any case, how will NTB7
behave? Was the anomaly due to Notetab or the RegEx engine?

For me, not supporting proportional fonts in NTP is a deal breaker.
It is not practical for me to install both and switch back and forth,
especially since their respective behaviors differ under identical
circumstances. I also resent the proposed policy of only offering
a package of both standard and pro versions. I do not appreciate
being forced to pay for something that I cannot use.

Note: I have use NTP and NTB above as shorthand for the pro
and standard versions respectively.

Namaste',  Art

--- In notetab@yahoogroups.com, Art Kocsis <artkns@...> wrote:
>
> In NTB 5.8/fv, the "^" RegEx operator seems to have a random
> behavior. (...) Sometimes NTB would act correctly and restrict
> the pattern to search from BOL. Other times it would start from
> anywhere. IIRC, Flo(?) at one time made the comment that in NTP
> (6?), a "^" search pattern could always start anyplace in the line.

Objection, Art! I wouldn't say that, and I don't know what you are referring to.

Also, I can't confirm that any version (since v.4.95) , including NTB 7.0, ever
interpreted the caret different than beginning of line (or paragraph).

Maybe someone said: '^' matches at ANY position -- not meaning at any position
in a line but at any beginning of a line in a whole document?

Regards,
Flo

Hi everyone,

Thanks again for all your feedback so far. As usual, I've tried my best
to fix all the reported issues. You can now download the latest
pre-release of NoteTab Light and NoteTab Pro Trial version 7.0:

NoteTab Light 7 (freeware)
http://www.notetab.com/ftp/NoteTab_Light_Setup.exe

NoteTab Pro 7 (30-day trial version)
http://www.notetab.com/ftp/NotePro_Trial_Setup.exe

Here's a list of the main changes since pre-release #5:

* To remove an undesired item from the Find/Replace lists, you can now
right-click in the field to open the popup menu and choose "Delete from
List"; you can also delete the whole history by choosing "Clear History".

* Fixed a bug that affected the text selection range in NoteTab Pro when
word wrap was turned on.

* Fixed an issue with HTML and CSS highlighting that failed to work
correctly when a line had one or more tab characters.

* Fixed highlighting issues with commented text in CSS files.

* Fixed ^$StrPos issue returning -1 instead of 0 on failed matches.

* Fixed some minor issues in ^$StrWordList and the Text Statistics feature.


I look forward to reading your comments and feedback.

--
Regards,

Eric Fookes
http://www.fookes.com/

Having problems with Clipbook editing - Using  NoteTab Std 4.95

While creating and  editing clips in a clipbook.

I can copy text from a document to the clipbook. BUT I can not edit
existing clips in a clipbook, unless I copy the text of the clip to a
new Clip, and  use the edit  menu to copy to V\Clipbook under a new clip
name, then delete the old one.

It then creates the new clip but will not let me save changes to the
clipbook. The one I copied to clipbook is there and  works ( I have
other  clip issues) But the  saving the clip book changes still is
locked out.

moderator note: Yikes! Apologies that this did not get posted.

Hi NTBers!

Using NoteTab, right now I try to crack a problem re a large list, ca
2mio records, stripped all other stuff away, so that only the strings
that need sorting remain. But I need to sort backwards, from right to
left. Then the duplicates need to be counted. Right now only the
R2L-sorting and the dupe-counting remain. Any ideas? Is there a plugin
for this?

So far spread sheets or database programs seam not to do it per se or I simply
do not know how to, yet ;) But it would be much easier, if
NoteTab could do it right with the text file in it, so no export/import would be
necessary.

Any help is much appreciated. This is not an Easter Egg, but you can
count it as an Easter Greeting :)

Thank you in advance and best wishes,
Milan


--




----------
Legal Note
This message, incl. potential attachments, is of confidential or
privileged nature and intended solely for individual/organization
addressed. If received in error, please notify sender at once and
destroy. Unintended use of message is forbidden/potentially illegal.
Salvatory and severance apply, estoppel is void, e.g. in that any
message or any part thereof shall be valid in their own context.
----------

--- In notetab@yahoogroups.com, "milanboran" <milan.boran@...> wrote:
>
> moderator note: Yikes! Apologies that this did not get posted.

If I'm not mistaken, this was was posted on Apr 7 with...

http://tech.groups.yahoo.com/group/ntb-scripts/message/523

Before anyone starts this topic anew it might be helpful to read what has been
posted since Apr 7 in the Scripts Group.

Regards,
Flo

Yes, this problem has been solved.

Many thanks to all who helped, especially
Don, Flo, Jonas, and Thomas.

Best regards,
Milan





On Fri, Apr 20, 2012 at 02:10, flo.gehrke <flo.gehrke@...> wrote:
>
>
>
> --- In notetab@yahoogroups.com, "milanboran" <milan.boran@...> wrote:
> >
> > moderator note: Yikes! Apologies that this did not get posted.
>
> If I'm not mistaken, this was was posted on Apr 7 with...
>
> http://tech.groups.yahoo.com/group/ntb-scripts/message/523
>
> Before anyone starts this topic anew it might be helpful to read what has been
posted since Apr 7 in the Scripts Group.
>
> Regards,
> Flo
>
>




--




----------
Legal Note
This message, incl. potential attachments, is of confidential or
privileged nature and intended solely for individual/organization
addressed. If received in error, please notify sender at once and
destroy. Unintended use of message is forbidden/potentially illegal.
Salvatory and severance apply, estoppel is void, e.g. in that any
message or any part thereof shall be valid in their own context.
----------

At 4/19/2012 09:01 AM, Flo wrote:
>--- In <mailto:notetab%40yahoogroups.com>notetab@yahoogroups.com, Art
>Kocsis <artkns@...> wrote:
> > In NTB 5.8/fv, the "^" RegEx operator seems to have a random
> > behavior. (...) Sometimes NTB would act correctly and restrict
> > the pattern to search from BOL. Other times it would start from
> > anywhere. IIRC, Flo(?) at one time made the comment that in NTP
> > (6?), a "^" search pattern could always start anyplace in the line.
>
>Objection, Art! I wouldn't say that, and I don't know what you are
>referring to.
>
>Also, I can't confirm that any version (since v.4.95) , including NTB 7.0,
>ever interpreted the caret different than beginning of line (or paragraph).
>
>Maybe someone said: '^' matches at ANY position -- not meaning at any
>position in a line but at any beginning of a line in a whole document?
>
>Regards,
>Flo

Hi Flo,

Sorry. I wasn't sure who posted that comment. That's why I had the "?".
The post was over a year ago, by a frequent female poster (IIRC) - [that's
why I thought of you or possibly Sheri], who uses Notetab Pro, discussed
differences in caret processing by Std & Pro and specifically said the caret
did not force the pattern to start at BOL which, to me, is exactly what the
caret is supposed to do! That is why the comment has stuck in my mind.
Unfortunately, I can't find the post to confirm exactly what was said but it
was not searching BOL for the entire doc.

I use NT Std 5.8/fv and once in a while the caret does not force BOL
matching. (And, no, I don't have any examples but I will post one the next
time it happens.)

Art

Long analysis follows (sorry). See summary at bottom.


>--- In <mailto:notetab%40yahoogroups.com>notetab@yahoogroups.com, Art
>Kocsis <artkns@...> wrote:
> > Although this is not new with v7, perhaps it is an opportunity to correct
> > this behavior.
> >
> > Select to end-of-line does not include the line termination
> character(s) in
> > most cases. It is true for all methods (mouse Shift-drag, keyboard
> > Shift-End or clip ^!Select EOL), in Notetab Pro but only for clip ^!Select
> > EOL in Notetab Std. Mouse Shift-drag and keyboard Shift-End does include
> > line terminations in Notetab Std (left to right but not right to left).
> The
> > inconsistency in Notetab Std is confusing and seems unnecessary. Since it
> > only affects the manual UI, the inconsistency could be removed without
> much
> > breakage.

At 4/17/2012 02:08 PM, Eb wrote:
>In the version 7, selecting to the end of the line, with or without the
>EOL is entirely up to the user, and consistent between NTPro and NTStd. At
>least as far as I've tested.
1) How are you testing v7 Std??? All Eric posted, and all I get for the
prerelease, is the pro version!

2) Including the line termination character(s) is NOT up to the user - it
is a behavior of the app. The UI DISPLAY of non-printing characters (which
includes the CRLF) in NTP is a user option - totally independent of any
selection. In NT Std, display of non-printing characters is not available
but a single blank screen position is highlighted for a CRLF when selected.

>I cannot duplicate any differences.
>You click on the begin of the line, the entire line, incl eol, is
>selected. Both editions.
Perhaps you need to look more carefully. Perhaps you didn't notice that the
cursor moved to the next line in NTP but doesn't in NT Std.

>Both the mouse and the cursor keys work the same way in Pro and Std. You
>do have to press the SHIFT key to make a selection with the keyboard.
Yes, Eb, I am very well aware of how Shift and Cntl-Shift keyboard
highlighting works. Thank you very much.

>Use the mouse or cursor key to drag the selection from the start to the
>end does NOT select the EOL character(s).
Yes it does in NT Standard! Tested in NT Std versions 4, 5 and 6.

>Use the mopuse or cursor to drag to the start of the next line DOES
>include the EOL.
Obviously. The discussion is about single line selections.

>^!Select EOL does NOT include the EOL
That is what I said.

>^!Select LINE DOES include it,
The post was primarily about UI differences but (see below), it turns out
there are critical clip differences as well.

>in both, Pro and Std.
>What methods have I missed, that are inconsistent?
See below.


Mouse behavior (With non-printing characters turned on in NTP):
==============================================
In NT Std (L-R): Clicking on BOL selects the entire line, including the
CRLF and LEAVES the cursor positioned at col 1 of the SAME line

In NT Pro (L-R): Clicking on BOL selects the entire line, including the
CRLF and but MOVES the cursor to col 1 of the NEXT line.

In NT Std (L-R): Sweeping the mouse from BOL to EOL selects the entire
line, INcluding the CRLF and LEAVES the cursor positioned on the same line
at BEGINNING OF LINE.

In NT Pro (L-R): Sweeping the mouse from BOL to EOL selects the entire
line, EXcluding the CRLF and MOVES the cursor on the same line but at the
END OF LINE.

(R-L): Sweeping the mouse from EOL to BOL selects the entire line, EXcluding
     the CRLF and positions the cursor at col 1 for both NT Std and NT Pro.

Keyboard behavior:
==============
Essentially identical behavior as with the mouse.
In NT Std (L-R): Pressing Shift-End from BOL selects the entire line,
INcluding the CRLF and LEAVES the cursor positioned on the same line at
BEGINNING OF LINE.

In NT Pro (L-R):  Pressing Shift-End from BOL selects the entire line,
EXcluding the CRLF and MOVES the cursor on the same line but at the END OF
LINE.

(R-L): Pressing Shift-Home from EOL selects the entire line, EXcluding
     the CRLF and positions the cursor at col 1 for both NT Std and NT Pro.

Clip behavior (Here's where it gets really messy)
===================================
In NT Std (L-R): ^!Select EOL from BOL selects the entire line, EXcluding
the CRLF
    The NT Std status line displays BOS/BOL values
    The clip Row:Col values are Beginning Of Selection (BOS) (same row, col 1)
    ^!Select 0 leaves the cursor positioned at BOS/BOL (same row, col 1)
    ^!MoveCursor +n starts from the EOS/EOL (before the CRLF)
    ^!MoveCursor -n starts from the BOS/BOL

In NT Pro (L-R): The CLIP behavior is identical (same selection, same
Row:Col values, same subsequent cursor movements), except for ^!Keyboard
Left | Right commands.
    The NT Pro STATUS LINE displays EOS/EOL values

These status bar display differences are also evident in the subsequent
clip behavior of ^!Keyboard ^!Keyboard Left | Right commands or if the clip
is canceled after the ^!Select EOL command (the selection is still
highlighted) and an arrow key is pressed.

In NT Std, a ^!Keyboard Left command starts from the BOS/BOL position and
moves the document position one character to the left (to the middle of the
CRLF pair!). A ^!Keyboard Right command starts from the EOS/EOL position
and moves the cursor position one document character to the right (again,
to the middle of the CRLF pair!).

In NT Pro, a ^!Keyboard Left command starts from the EOS/EOL position and
moves the cursor position one character to the left. A ^!Keyboard Right
command, also starts from the EOS/EOL position but treats the CRLF
character pair as a single character and moves the cursor TWO
document  positions to the right.

Similarly, if a clip is canceled while the selection is still highlighted,
immediately pressing an arrow yields identical results as the respective
clip ^!Keyboard behavior in both Std and Pro version.

Clip behavior for Right to Left selection is identical to the Left to Right
behavior.
Cursor position subsequent to the selection is independent of L-R or R-L
selection. Subsequent ^!MoveCursor +/- and ^!Select 0 behavior is
identical. The abovementioned status line value differences also appear and
are independent of selection direction. The ^!Keyboard Left | Right and
arrow key left | right behavior differences also repeat.

So, in summary:
============
The UIs differ between the Starndard and Pro versions. They are annoying,
not critical.

Clip processing for the two versions are identical for ^!Select 0 | EOL |
BOL and ^!MoveCursor + | - but different and potentially dangerous for
^!Keyboard Left | Right.

NT Pro treats a CRLF pair as a single character in clips whereas NT Std
sees them as two separate characters. Both UIs treat them as a single
character.

Nitty gritty cursor position clip programming is a b****h!

This started out as a simple reply and grew into a major project!   Aargh!!!

Art

PS - If you really want to see for yourself here is some test clip to play
with:
;Testing Select to EOL differences in NTB Std vs NTB Pro
;Change comment chars as appropriate.

^!Jump Line_Start
^!Select EOL
;   or
^!Jump Line_End
^!Select BOL
^!Continue  Row:Col = ^$GetRow$:^$GetCol$
;^!Select 0
;^!MoveCursor -4
;^!MoveCursor +4
;^!Keyboard Left
;^!Keyboard Left
^!Keyboard Right
^!Keyboard Right
^!Continue  Row:Col = ^$GetRow$:^$GetCol$

I had this problem also, and Dio helped me out of it. It amounted to rewriting
the clip to avoid the ^ being in the
location it was in. I'm not sure I have the old correspondence, but if I can
find it, I'll post something. My archives
are saved off in external files, so I have to activate them and then search. I
wonder how many people have email
archives back to 1992 on their computers? Not everything, of course, but
important enough to keep.

In my case, it was Pro not working the correct way in every instance. It
absolutely required rewriting to avoid the
trap. I do remember posting it, so there is a record somewhere.

Regards,
John
RecipeTools Web Site:  <http://recipetools.gotdns.com/>
http://recipetools.gotdns.com/

From: notetab@yahoogroups.com [mailto:notetab@yahoogroups.com] On Behalf Of Art
Kocsis
Sent: Friday, April 20, 2012 12:14
To: NoteTab-Basic
Subject: Re: [NTB] Std vs Pro Caret Processing


At 4/19/2012 09:01 AM, Flo wrote:
>--- In <mailto:notetab%40yahoogroups.com>notetab@yahoogroups.com
<mailto:notetab%40yahoogroups.com> , Art
>Kocsis <artkns@...> wrote:
> > In NTB 5.8/fv, the "^" RegEx operator seems to have a random
> > behavior. (...) Sometimes NTB would act correctly and restrict
> > the pattern to search from BOL. Other times it would start from
> > anywhere. IIRC, Flo(?) at one time made the comment that in NTP
> > (6?), a "^" search pattern could always start anyplace in the line.
>
>Objection, Art! I wouldn't say that, and I don't know what you are
>referring to.
>
>Also, I can't confirm that any version (since v.4.95) , including NTB 7.0,
>ever interpreted the caret different than beginning of line (or paragraph).
>
>Maybe someone said: '^' matches at ANY position -- not meaning at any
>position in a line but at any beginning of a line in a whole document?
>
>Regards,
>Flo

Hi Flo,

Sorry. I wasn't sure who posted that comment. That's why I had the "?".
The post was over a year ago, by a frequent female poster (IIRC) - [that's
why I thought of you or possibly Sheri], who uses Notetab Pro, discussed
differences in caret processing by Std & Pro and specifically said the caret
did not force the pattern to start at BOL which, to me, is exactly what the
caret is supposed to do! That is why the comment has stuck in my mind.
Unfortunately, I can't find the post to confirm exactly what was said but it
was not searching BOL for the entire doc.

I use NT Std 5.8/fv and once in a while the caret does not force BOL
matching. (And, no, I don't have any examples but I will post one the next
time it happens.)

Art



[Non-text portions of this message have been removed]

Here are a few more bugs that still exist in Notetab 7:

Drag-Copy Cursor:
The Plus sign still missing from the drag-copy cursor.
Pressing the Cntl key while dragging a selection has
no effect. This is dangerous and violates the basic UI
and premise of Windows of having standard methods for
Windows apps.

Change Icon: If the AppIconIndex value under [Options]
in the INI file is greater than the max index of the
icon group of the exe file, no icon will show in View |
Options | Change Icon nor can it be changed.


Allow Reordering Tabs:
The Allow Reordering right-click tab option is not
available unless Stack Tabs is enabled. Tab reordering
should be independent of the Stack Tabs setting and is
especially useful when Stack Tabs is disabled. In addition,
the Allow Reordering setting should be persistent.

Line-terminator display:
With Show Non-printing Text enabled, there is an extra,
non-existent line-terminator displayed at the EOF. This
is misleading. To verify, create a new document and
observe that a line-terminator is displayed but does not
exist in the saved file. Similarly, for all documents,
the last line-terminator at the EOF does not exist.

BTW: There is a UseRegistry=0 entry in the [Application]
section of the default INI file. Will NoteTab still use
the registry for its settings if this value is reset to 1?

Namaste',   Art

--- In notetab@yahoogroups.com, Art Kocsis <artkns@...> wrote:
>
> Hi Flo,
>
> The post was over a year ago (...) that's why I thought of
> you or possibly Sheri, who uses Notetab Pro, discussed
> differences in caret processing by Std & Pro and specifically
> said the caret did not force the pattern to start at BOL...

Art,

If we talk about...

- differences between NTb Pro and Standard,
- with regard to the caret,
- and postings from Sheri,

then I remember message #17366 of Jan 27, 2008 in the CLIP group.

It refers to the first page of 'Help on Regular Expressions' ("NoteTab and
PCRE/Note to clippers...") and describes a difference regarding the search
within highlighted text.

So the subject is neither RegEx nor NTb in general but a rather specific issue
and behavior.

When testing this behavior, you will see that, even in this context, the caret
matches at the beginning of a line (or paragraph) only.

Regards,
Flo

I stand by my limited test results, made with NTP 7 prerelease #5, and NTS 7
prerelease #3.

I'll try to duplicate some of your tests when I get matching prereleases for Pro
and Std.


Eb


--- In notetab@yahoogroups.com, Art Kocsis <artkns@...> wrote:
> ...
> Keyboard behavior:
> ==============
> Essentially identical behavior as with the mouse.
> In NT Std (L-R): Pressing Shift-End from BOL selects the entire line,
> INcluding the CRLF and LEAVES the cursor positioned on the same line at
> BEGINNING OF LINE.

This is affected by paragraph wrapping or not.


>
> In NT Pro (L-R):  Pressing Shift-End from BOL selects the entire line,
> EXcluding the CRLF and MOVES the cursor on the same line but at the END OF
> LINE.
>
> (R-L): Pressing Shift-Home from EOL selects the entire line, EXcluding
>     the CRLF and positions the cursor at col 1 for both NT Std and NT Pro.
>
> Clip behavior (Here's where it gets really messy)
> ===================================
> In NT Std (L-R): ^!Select EOL from BOL selects the entire line, EXcluding
> the CRLF
>    The NT Std status line displays BOS/BOL values
>    The clip Row:Col values are Beginning Of Selection (BOS) (same row, col 1)
>    ^!Select 0 leaves the cursor positioned at BOS/BOL (same row, col 1)
>    ^!MoveCursor +n starts from the EOS/EOL (before the CRLF)
>    ^!MoveCursor -n starts from the BOS/BOL
>
> In NT Pro (L-R): The CLIP behavior is identical (same selection, same
> Row:Col values, same subsequent cursor movements), except for ^!Keyboard
> Left | Right commands.
>    The NT Pro STATUS LINE displays EOS/EOL values
>
> These status bar display differences are also evident in the subsequent
> clip behavior of ^!Keyboard ^!Keyboard Left | Right commands or if the clip
> is canceled after the ^!Select EOL command (the selection is still
> highlighted) and an arrow key is pressed.
>
> In NT Std, a ^!Keyboard Left command starts from the BOS/BOL position and
> moves the document position one character to the left (to the middle of the
> CRLF pair!). A ^!Keyboard Right command starts from the EOS/EOL position
> and moves the cursor position one document character to the right (again,
> to the middle of the CRLF pair!).
>
> In NT Pro, a ^!Keyboard Left command starts from the EOS/EOL position and
> moves the cursor position one character to the left. A ^!Keyboard Right
> command, also starts from the EOS/EOL position but treats the CRLF
> character pair as a single character and moves the cursor TWO
> document  positions to the right.
>
> Similarly, if a clip is canceled while the selection is still highlighted,
> immediately pressing an arrow yields identical results as the respective
> clip ^!Keyboard behavior in both Std and Pro version.
>
> Clip behavior for Right to Left selection is identical to the Left to Right
> behavior.
> Cursor position subsequent to the selection is independent of L-R or R-L
> selection. Subsequent ^!MoveCursor +/- and ^!Select 0 behavior is
> identical. The abovementioned status line value differences also appear and
> are independent of selection direction. The ^!Keyboard Left | Right and
> arrow key left | right behavior differences also repeat.
>
> So, in summary:
> ============
> The UIs differ between the Starndard and Pro versions. They are annoying,
> not critical.
>
> Clip processing for the two versions are identical for ^!Select 0 | EOL |
> BOL and ^!MoveCursor + | - but different and potentially dangerous for
> ^!Keyboard Left | Right.
>
> NT Pro treats a CRLF pair as a single character in clips whereas NT Std
> sees them as two separate characters. Both UIs treat them as a single
> character.
>
> Nitty gritty cursor position clip programming is a b****h!
>
> This started out as a simple reply and grew into a major project!   Aargh!!!
>
> Art
>
> PS - If you really want to see for yourself here is some test clip to play
> with:
> ;Testing Select to EOL differences in NTB Std vs NTB Pro
> ;Change comment chars as appropriate.
>
> ^!Jump Line_Start
> ^!Select EOL
> ;   or
> ^!Jump Line_End
> ^!Select BOL
> ^!Continue  Row:Col = ^$GetRow$:^$GetCol$
> ;^!Select 0
> ;^!MoveCursor -4
> ;^!MoveCursor +4
> ;^!Keyboard Left
> ;^!Keyboard Left
> ^!Keyboard Right
> ^!Keyboard Right
> ^!Continue  Row:Col = ^$GetRow$:^$GetCol$
>

At 4/21/2012 02:16 AM, Flo wrote:
>--- In <mailto:notetab%40yahoogroups.com>notetab@yahoogroups.com, Art
>Kocsis <artkns@...> wrote:
> > Hi Flo,
> > The post was over a year ago (...) that's why I thought of
> > you or possibly Sheri, who uses Notetab Pro, discussed
> > differences in caret processing by Std & Pro and specifically
> > said the caret did not force the pattern to start at BOL...
>Art,
>
>If we talk about...
>- differences between NTb Pro and Standard,
>- with regard to the caret,
>- and postings from Sheri,
>
>then I remember message #17366 of Jan 27, 2008 in the CLIP group.
>
>It refers to the first page of 'Help on Regular Expressions' ("NoteTab and
>PCRE/Note to clippers...") and describes a difference regarding the search
>within highlighted text.
>
>So the subject is neither RegEx nor NTb in general but a rather specific
>issue and behavior.
>
>When testing this behavior, you will see that, even in this context, the
>caret matches at the beginning of a line (or paragraph) only.

Flo,

That's not the post I saw. I didn't rejoin the clip list until June 2008 so
I wouldn't even have seen that one. I've spent hours searching my archives
using every keyword I could remember to no avail. I've (we've) spent way
too much time on this for what it is worth so I'll have to let it go.
Thanks for trying though.

As I understand it, the caret is supposed to force a pattern search from
the start of a line and you are confirming that. I'm good with that. If I
run into another case where it  fails I will post it.

Thanks again,  Art

At 4/20/2012 09:31 PM, I wrote:
>Allow Reordering Tabs:
>The Allow Reordering right-click tab option is not
>available unless Stack Tabs is enabled. Tab reordering
>should be independent of the Stack Tabs setting and is
>especially useful when Stack Tabs is disabled. In addition,
>the Allow Reordering setting should be persistent.

Correction: I haven't changed this setting in a long time as I
leave Stack Tabs always enabled. I forgot that when Stack
Tabs is disabled, Allow Reordering is always enabled so no
need for an option.

Sorry for the misinformation. However, I still think the Allow
Reordering setting should be persistent as it is a PITA to
have to reset it every time I want to move the  tabs.

Namaste',   Art

The HTML code highlighting in Beta 6 is still flaky. When I edit the
code (inserting/deleting characters) it often loses track of where it
should begin or end the highlight. I have to reload the file to fix the
issue. This is particularly noticeable in large replaces.

This was not an issue in previous versions.
--
MCBastos

This message has been protected with the 2ROT13 algorithm. Unauthorized
use will be prosecuted under the DMCA.

-=-=-
... Sent from my Amiga 1200.
* Added by TagZilla 0.7a1 running on Seamonkey 2.8 *
Get it at http://xsidebar.mozdev.org/modifiedmailnews.html#tagzilla

Hi Marcelo,

> The HTML code highlighting in Beta 6 is still flaky. When I edit the
> code (inserting/deleting characters) it often loses track of where it
> should begin or end the highlight. I have to reload the file to fix the
> issue. This is particularly noticeable in large replaces.

Thanks for your feedback. Unfortunately, I don't seem to work the same
way as you and haven't been able to reproduce the issue. Can you provide
specific steps that cause the highlighting to get out of sync?

--
Regards,

Eric Fookes
http://www.fookes.com/

Hi Art,

> Sorry for the misinformation. However, I still think the Allow
> Reordering setting should be persistent as it is a PITA to
> have to reset it every time I want to move the  tabs.

Many years ago this setting was persistent. Unfortunately, people forgot
about the setting and got confused when their tabs would shift position
if not clicked carefully. It cause a lot of customer support mail, which
is why I decided to turn off the persistence. This change had a dramatic
effect on customer support queries.

Note that you can double-click on a tab to toggle the Reordering setting.

--
Regards,

Eric Fookes
http://www.fookes.com/

Hi Art,

> Drag-Copy Cursor:
> The Plus sign still missing from the drag-copy cursor.
> Pressing the Cntl key while dragging a selection has
> no effect. This is dangerous and violates the basic UI
> and premise of Windows of having standard methods for
> Windows apps.

There is no standard Windows cursor with a plus sign for drag-copy. Of
course, applications can use their own bitmaps for specific tasks.
However, NoteTab just uses the standard cursors available to it.

> Change Icon: If the AppIconIndex value under [Options]
> in the INI file is greater than the max index of the
> icon group of the exe file, no icon will show in View |
> Options | Change Icon nor can it be changed.

Thanks. This will be fixed in the next update.

> Line-terminator display:
> With Show Non-printing Text enabled, there is an extra,
> non-existent line-terminator displayed at the EOF. This
> is misleading. To verify, create a new document and
> observe that a line-terminator is displayed but does not
> exist in the saved file. Similarly, for all documents,
> the last line-terminator at the EOF does not exist.

Unlike the Rich-Edit input control used in NoteTab Light and Std, line
terminators are not stored in the NoteTab Pro input control. If the
display of line-terminator symbols disturbs you, simply uncheck the
View/Nonprinting Text menu option.

> BTW: There is a UseRegistry=0 entry in the [Application]
> section of the default INI file. Will NoteTab still use
> the registry for its settings if this value is reset to 1?

It's provided for backwards compatibility purposes only. You shouldn't
edit its value in the INI file.

--
Regards,

Eric Fookes
http://www.fookes.com/

At 4/24/2012 03:05 AM, Eric Fookes wrote:

>Many years ago this setting was persistent. <snip> It cause a lot of
>customer support mail, which is why I decided to turn off the persistence.
>This change had a dramatic effect on customer support queries.
Thank you for the explanation. That makes sense and removes the annoyance.


>Note that you can double-click on a tab to toggle the Reordering setting.
OK! That works and hardly takes any extra effort. Where is that documented?

Thanks,  Art

At 4/24/2012 10:23 AM, Eric Fookes wrote:
> > Drag-Copy Cursor:
> > The Plus sign still missing from the drag-copy cursor.
> > Pressing the Cntl key while dragging a selection has
> > no effect. This is dangerous and violates the basic UI
> > and premise of Windows of having standard methods for
> > Windows apps.
>
>There is no standard Windows cursor with a plus sign for drag-copy. Of
>course, applications can use their own bitmaps for specific tasks.
>However, NoteTab just uses the standard cursors available to it.

Thank you for responding.

I didn't say standard Windows cursor - I said standard Windows UI.
Are there two (or more), different (overlapping), UIs embedded in
Windows? If so, that is a major design flaw in Windows.

Notetab Std adds the little plus sign while the Cntrl key is pressed,
NotePro does not. What are the "cursors available" to them and why
are they different? Please don't say because you are using different
input controls as that begs the question: why use different controls.

Art

Hi Art,

On 25 Apr 12 01:40 Art Kocsis <artkns@...> said:
> that begs the question: why use different controls

Well, that one's easy...  Because NoteTab is not a single product.
Standard and Pro are aimed at different audiences that require
different facilities. Accordingly, they use input controls appropriate
for the tasks that the different audiences need. In the same way that
other text editors are different again to either Standard or Pro.

Rather than be surprised at the differences between Standard and Pro,
you should be expressing your surprise at how similar they are,
compared to all other editors around.

Greg

Hi Art,

>> Note that you can double-click on a tab to toggle the Reordering setting.
> OK! That works and hardly takes any extra effort. Where is that documented?

Under Tips and How to...

"When you have several documents open, you can drag-and-drop page tabs
to reorder them any way you like. If the tabs are stacked, you will
first have to enable drag-and-drop by double clicking on the tab before
moving it."

--
Regards,

Eric Fookes
http://www.fookes.com/

Hi everyone,

Recently there have been several posts questioning "unexpected"
differences between NoteTab Std/Light and Pro. Although this has been
explained many times in the past, I realize this may have been quite a
few years ago. So here's a fresh explanation on the subject. I hope you
find useful.

NoteTab Std/Light uses the Windows Rich-Edit input control and NoteTab
Pro uses a third-party input control. These have very different
characteristics.

In 1996, the first versions of NoteTab used the Windows Rich-Edit input
control. There was no Pro version then.

Then in 1997, I found a third-party input control that offered many
benefits over the Rich-Edit input control. It was extremely fast (and
still is) as it was highly optimized with lots of ASM code. It also
offered many other benefits that were not available in the Rich-Edit
input control. At that time, it was by far the best third-party input
control. That's the input control that I used to develop NoteTab Pro.

NoteTab Pro did (and still does) have one notable disadvantage over
NoteTab Std/Light. It only supports mono-spaced fonts. Because that was
an issue with some users, I decided to keep both NoteTab variants.

Nowadays there are many third-party input controls available to
developers. Most offer advanced features that weren't available in 1997
but are now popular with programmers. A couple of the best input
controls are used in many competing text editors today. Did you ever
wonder why they all have such similar capabilities?

I can hear you ask "why doesn't Fookes Software just use one of those
great new input controls in NoteTab?"

The reason is simple. NoteTab is based on a lot of optimized ASM and
fast legacy code. Unfortunately, to use today's input controls requires
updating NoteTab's source code to support Unicode. This is a difficult
and extremely time consuming task. As I explained in an earlier email,
it is easier to develop a new NoteTab editor than to update the legacy
program code.

Why bother develop a NoteTab 7 version based on the old code? Well, it's
a lot faster than writing a brand new editor that is as good as NoteTab.
And I still think that NoteTab is a superb product. It may not look as
pretty as some of the newer text editors, but you can get a lot more
work done in NoteTab than with the competition. You'll have a hard time
finding an editor that is as fast as NoteTab Pro and also as feature rich.

Yes, NoteTab does have some weaknesses compared to many of the newer
text editors. But they only really affect a small number of users. And I
dare say these weaknesses are nothing compared to the many unique
productivity features NoteTab offers.

--
Regards,

Eric Fookes
http://www.fookes.com/

Hi Art,

>> There is no standard Windows cursor with a plus sign for drag-copy. Of
>> course, applications can use their own bitmaps for specific tasks.
>> However, NoteTab just uses the standard cursors available to it.
>
> Thank you for responding.
>
> I didn't say standard Windows cursor - I said standard Windows UI.
> Are there two (or more), different (overlapping), UIs embedded in
> Windows? If so, that is a major design flaw in Windows.

Here's what's available with the standard Windows UI:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms648391(v=vs.85).aspx

You can see images of those cursors on this page:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb545459.aspx#concepts

> Notetab Std adds the little plus sign while the Cntrl key is pressed,
> NotePro does not. What are the "cursors available" to them and why
> are they different? Please don't say because you are using different
> input controls as that begs the question: why use different controls.

Well, there is an explanation in Help about the differences between
NoteTab Std/Light and Pro. They are based on completely different types
of input controls.

I've decided to post a separate email with the subject "Differences
between NoteTab Std/Light and Pro explained" that will hopefully help
you better understand what's going on.

--
Regards,

Eric Fookes
http://www.fookes.com/

Art, I've confirmed your results and summarized them - in the clip list, as my
answer contains a clip to display hidden characters.

Cheers,

Eb

--- In notetab@yahoogroups.com, "Eb" <ebbtidalflats@...> wrote:
>
> I stand by my limited test results, made with NTP 7 prerelease #5, and NTS 7
prerelease #3.
>
> I'll try to duplicate some of your tests when I get matching prereleases for
Pro and Std.
>
>
> Eb
>
>
> --- In notetab@yahoogroups.com, Art Kocsis <artkns@> wrote:
> > ...
> > Keyboard behavior:
> > ==============
> > Essentially identical behavior as with the mouse.
> > In NT Std (L-R): Pressing Shift-End from BOL selects the entire line,
> > INcluding the CRLF and LEAVES the cursor positioned on the same line at
> > BEGINNING OF LINE.
>
> This is affected by paragraph wrapping or not.
>
>
> >
> > In NT Pro (L-R):  Pressing Shift-End from BOL selects the entire line,
> > EXcluding the CRLF and MOVES the cursor on the same line but at the END OF
> > LINE.
> >
> > (R-L): Pressing Shift-Home from EOL selects the entire line, EXcluding
> >     the CRLF and positions the cursor at col 1 for both NT Std and NT Pro.
> >
> > Clip behavior (Here's where it gets really messy)
> > ===================================
> > In NT Std (L-R): ^!Select EOL from BOL selects the entire line, EXcluding
> > the CRLF
> >    The NT Std status line displays BOS/BOL values
> >    The clip Row:Col values are Beginning Of Selection (BOS) (same row, col
1)
> >    ^!Select 0 leaves the cursor positioned at BOS/BOL (same row, col 1)
> >    ^!MoveCursor +n starts from the EOS/EOL (before the CRLF)
> >    ^!MoveCursor -n starts from the BOS/BOL
> >
> > In NT Pro (L-R): The CLIP behavior is identical (same selection, same
> > Row:Col values, same subsequent cursor movements), except for ^!Keyboard
> > Left | Right commands.
> >    The NT Pro STATUS LINE displays EOS/EOL values
> >
> > These status bar display differences are also evident in the subsequent
> > clip behavior of ^!Keyboard ^!Keyboard Left | Right commands or if the clip
> > is canceled after the ^!Select EOL command (the selection is still
> > highlighted) and an arrow key is pressed.
> >
> > In NT Std, a ^!Keyboard Left command starts from the BOS/BOL position and
> > moves the document position one character to the left (to the middle of the
> > CRLF pair!). A ^!Keyboard Right command starts from the EOS/EOL position
> > and moves the cursor position one document character to the right (again,
> > to the middle of the CRLF pair!).
> >
> > In NT Pro, a ^!Keyboard Left command starts from the EOS/EOL position and
> > moves the cursor position one character to the left. A ^!Keyboard Right
> > command, also starts from the EOS/EOL position but treats the CRLF
> > character pair as a single character and moves the cursor TWO
> > document  positions to the right.
> >
> > Similarly, if a clip is canceled while the selection is still highlighted,
> > immediately pressing an arrow yields identical results as the respective
> > clip ^!Keyboard behavior in both Std and Pro version.
> >
> > Clip behavior for Right to Left selection is identical to the Left to Right
> > behavior.
> > Cursor position subsequent to the selection is independent of L-R or R-L
> > selection. Subsequent ^!MoveCursor +/- and ^!Select 0 behavior is
> > identical. The abovementioned status line value differences also appear and
> > are independent of selection direction. The ^!Keyboard Left | Right and
> > arrow key left | right behavior differences also repeat.
> >
> > So, in summary:
> > ============
> > The UIs differ between the Starndard and Pro versions. They are annoying,
> > not critical.
> >
> > Clip processing for the two versions are identical for ^!Select 0 | EOL |
> > BOL and ^!MoveCursor + | - but different and potentially dangerous for
> > ^!Keyboard Left | Right.
> >
> > NT Pro treats a CRLF pair as a single character in clips whereas NT Std
> > sees them as two separate characters. Both UIs treat them as a single
> > character.
> >
> > Nitty gritty cursor position clip programming is a b****h!
> >
> > This started out as a simple reply and grew into a major project!   Aargh!!!
> >
> > Art
> >
> > PS - If you really want to see for yourself here is some test clip to play
> > with:
> > ;Testing Select to EOL differences in NTB Std vs NTB Pro
> > ;Change comment chars as appropriate.
> >
> > ^!Jump Line_Start
> > ^!Select EOL
> > ;   or
> > ^!Jump Line_End
> > ^!Select BOL
> > ^!Continue  Row:Col = ^$GetRow$:^$GetCol$
> > ;^!Select 0
> > ;^!MoveCursor -4
> > ;^!MoveCursor +4
> > ;^!Keyboard Left
> > ;^!Keyboard Left
> > ^!Keyboard Right
> > ^!Keyboard Right
> > ^!Continue  Row:Col = ^$GetRow$:^$GetCol$
> >
>

Hi everyone,

Thanks for all your latest feedback. Here's, hopefully, the last
pre-release update before NoteTab 7.0 is launched. I plan to release the
final version next Monday unless you find a showstopper before then.

You can download the pre-release #7 of NoteTab Light and NoteTab Pro
Trial from here:

NoteTab Light 7 (freeware)
http://www.notetab.com/ftp/NoteTab_Light_Setup.exe

NoteTab Pro 7 (30-day trial version)
http://www.notetab.com/ftp/NotePro_Trial_Setup.exe

Here's a list of the main changes since pre-release #6:

* Added a Clip command to delete the current text selection:
^!DeleteSelection

* Updated the Bootstrap library to match changes in the newly released
version 2.03.

* When the Word Count feature is enabled in the status bar, detailed
text statistics are now automatically displayed when you select a
certain amount of text (no longer necessary to click on the status bar).

* Improved the behavior of Clips when you drag-and-drop them into a
document. The cursor is correctly positioned in the pasted text the same
way as when you double-click a Clip.

* Fixed a randomly occurring bug affecting sentence counting.

* Fixed an issue in NTS/NTL with ^!MoveCursor -1 when the cursor is at
the start of the document and ^!MoveCursor +1 when it is at the end of
the document.


I look forward to reading your comments and feedback.

--
Regards,

Eric Fookes
http://www.fookes.com/

How do I register my product? I purchased my product (NoteTab Pro 6.2/fv) a few
weeks ago (through a Trial Pay offer) and want to know how I can get the free
upgrade to 7.0.

Thanks,
Pam Erickson


--- In notetab@yahoogroups.com, Eric Fookes <egroups@...> wrote:
>

> Customers who purchased NoteTab this year will be entitled to a free
> upgrade.