Request:

Please add a "Count Ocurrences" check box option to the Find dialog similar
to the Find & Replace dialog. It is inconvenient to switch back and forth
as well as F&R risks inadvertently changing the document if one has a
twitchy click finger.

Art

At 4/4/2012 02:00 PM, you wrote:
>NoteTab Pro 7 (30-day trial version)
><http://www.notetab.com/ftp/NotePro_Trial_Setup.exe>http://www.notetab.com/ftp/\
NotePro_Trial_Setup.exe

Hiya:

User for 10+ years, never a problem (except I always wonder why I can't get NTP
to accept cursor "snap to").  So today I must've hit the keyboard "insert" key,
and nothing I do will correct the cursor placement and insert characteristics: I
must be one space further right than the space I want to type into in order to
type into it; if I'm at the space I want to affect, it inserts one space further
left.  This does not happen in any other app I've tried.

Help??!!

Regards and Happy Trails,

Scott Needham
Boulder, Colorado, USA

Update: reinstalled 4.65, and it still does this.  Weird. NOthing I do on the
keyboard changes it (is there an alt+insert, cntl+insert etc fix?); it also will
take the space previous to the cursor with it when I use enter or tab keys....

--- In notetab@yahoogroups.com, "jsn_colorado" <needhamscott@...> wrote:
>
> Hiya:
>
> User for 10+ years, never a problem (except I always wonder why I can't get
NTP to accept cursor "snap to").  So today I must've hit the keyboard "insert"
key, and nothing I do will correct the cursor placement and insert
characteristics: I must be one space further right than the space I want to type
into in order to type into it; if I'm at the space I want to affect, it inserts
one space further left.  This does not happen in any other app I've tried.
>
> Help??!!
>
> Regards and Happy Trails,
>
> Scott Needham
> Boulder, Colorado, USA
>

On 2012-04-11 17:24, jsn_colorado wrote:
>
> Update: reinstalled 4.65, and it still does this. Weird. NOthing I do
> on the keyboard changes it (is there an alt+insert, cntl+insert etc
> fix?); it also will take the space previous to the cursor with it when
> I use enter or tab keys....
>
> --- In notetab@yahoogroups.com <mailto:notetab%40yahoogroups.com>,
> "jsn_colorado" <needhamscott@...> wrote:
> >
> > Hiya:
> >
> > User for 10+ years, never a problem (except I always wonder why I
> can't get NTP to accept cursor "snap to"). So today I must've hit the
> keyboard "insert" key, and nothing I do will correct the cursor
> placement and insert characteristics: I must be one space further
> right than the space I want to type into in order to type into it; if
> I'm at the space I want to affect, it inserts one space further left.
> This does not happen in any other app I've tried.
Scott: Sounds like you accidentally clicked in the Insert/Overstrike
toggle (2nd field from left on status bar at bottom of Notetab window).
If I've misread your post please ask again.
--
Regards ... Alec (buralex@gmail & WinLiveMess - alec.m.burgess@skype)


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

Thx--didn't even know it was there.  I think it is cleared up.


--- In notetab@yahoogroups.com, Alec Burgess <buralex@...> wrote:
>
> On 2012-04-11 17:24, jsn_colorado wrote:
> >
> > Update: reinstalled 4.65, and it still does this. Weird. NOthing I do
> > on the keyboard changes it (is there an alt+insert, cntl+insert etc
> > fix?); it also will take the space previous to the cursor with it when
> > I use enter or tab keys....
> >
> > --- In notetab@yahoogroups.com <mailto:notetab%40yahoogroups.com>,
> > "jsn_colorado" <needhamscott@> wrote:
> > >
> > > Hiya:
> > >
> > > User for 10+ years, never a problem (except I always wonder why I
> > can't get NTP to accept cursor "snap to"). So today I must've hit the
> > keyboard "insert" key, and nothing I do will correct the cursor
> > placement and insert characteristics: I must be one space further
> > right than the space I want to type into in order to type into it; if
> > I'm at the space I want to affect, it inserts one space further left.
> > This does not happen in any other app I've tried.
> Scott: Sounds like you accidentally clicked in the Insert/Overstrike
> toggle (2nd field from left on status bar at bottom of Notetab window).
> If I've misread your post please ask again.
> --
> Regards ... Alec (buralex@gmail & WinLiveMess - alec.m.burgess@skype)
>
>
> [Non-text portions of this message have been removed]
>

Hi everyone,

Thanks again for all your feedback so far. 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 #3:

* Brand new program icon (hope you like it). NTL, NTS, and NTP each have
their distinctive color.

* NTP: Added easy-on-the-eyes CSS syntax highlighting.

* NTP: Improved HTML syntax highlighting, notably in pages that contain
PHP, ASP, and Javascript code.

* Improved the Strip HTML Tags feature with better handling of documents
that contain PHP, ASP, and Javascript code.


I've used a new method for the syntax highlighting in HTML and CSS
documents. The challenge was to sacrifice as little performance as
possible while making it more reliable, especially in documents that
contain PHP, ASP, and Javascript code.

The difficulty in developing this new method was to ensure that the
syntax highlighting remains always synchronized while editing the code.
Although I've spent hours testing, there may be certain processes that
will create highlighting errors. If you discover such an issue, please
provide instructions so that I can reproduce it at my end.

Note that at this stage I am not planning on adding more new features --
otherwise v7 will never launch <g>. But I will continue to fix bugs that
you report, or at least try.

I look forward to reading your comments and feedback.

--
Regards,

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

Hi everyone,

Eb found a bug in v7 that affects searches in Outlook and Library files.
Since there is a small risk this can cause loss of data when a replace
operation is performed, I have quickly uploaded a fix. Note also that
the trial period for NoteTab Pro is reset to a full 30 days. Download
pre-release #5 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


I look forward to your comments and feedback.

--
Regards,

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

Thank you for implementing the ability to delete Find/F&R history
deletions. Would you also add a "Right Click | Delete" option? This would
eliminate having to continually shift between mouse and keyboard. It would
also open the door for further enhancements such as sorting the history list.

The new requirement to confirm "Close All" is an annoyance. It is also
inconsistent with closing the Notetab instance. There is now no feedback
when clicking the X in the upper right corner nor upon "Right Click
|  Close" on the task bar icon. I can understand the motivation but it
needs to be optional. There are other Notetab behaviors that are far more
dangerous than closing tabs, such as "replace all" in clip libs or outline
docs.

The Shift and Cntl-Shift drag and drop Cursor is still identical. It is
dangerous to not have user feedback to differentiate between move and copy.

Namste',  Art


At 4/16/2012 06:33 AM, you wrote:
>Hi everyone,
>I look forward to your comments and feedback.

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