My thoughts on multiple topics over the past few days
Forgive me for lumping several topics together. I wouldn't have time otherwise.
I, too, was in the same NoteTab beginner boat so I know what it feels like. Clipcode is quite unique but very predictable and usually easy to read when written clearly with comments. As a programmer who has had to learn many languages over the years, I hope I don't sound (fill in any one of several words) when I offer my advice which is to read the manual. Several times if you can. It's certainly not the most detailed or clear at times, but it does answer many questions I'm seeing, gives information and prevents surprise bugs because it is such a flexible language and loose on the syntax checking. And there are so many commands, I've often found some I didn't know about because of the information overload.
It is also VERY helpful to go through as much code (from other people) as you can find to learn new things that you missed in the help files or that weren't mentioned. I've learned a huge amount by doing that and by following discussions like this one.
I don't see it done often but don't see anything wrong with someone posting some code that works but seems long, obtuse or overly complicated and asking if someone knows how to rewrite it better. I'm sure many of the replies would be very educational.
Also, it's fine to ask if someone already has a clip to do one thing or another for ready to use or for a template.
On the topics of the last few days...
The manual does state
New since NoteTab 4.8: conditional commands now accept a command statement instead of a label.
Although it seems to work without quotes (I haven't tested), the syntax for IsAlpha requires quotes around the argument. Not using quotes may cause it not to work correctly in certain cases.
The IF statement cannot use logical arguments such as AND and OR.although there are ways I've written about several times to emulate this feature. Ask if you are interested and cannot find it.
A regexp way to replace the last comma in a string.
Lotta's way is easier to debug and understand. This way is shorter and for educational purposes because it was only recently I discovered regexp is permitted in StrReplace. (I still don't think well in regexp so I'm sure this can be improved upon)
; ^!Set %pos%=^$StrPosRight(",";"^%axel%";false)$
; ^!Set %axel%=^$StrDelete("^%axel%";^%pos%;1)$
; ^!Set %axel%=^$StrInsert("&";"^%axel%";^%pos%)$
Regarding Help with Message boxes
I think I understand the question and I think useful answers were given but I'm not sure so here are my thoughts...
To process part of a file and stop to have it examined and then to continue, some things need be done. The first is to remember the location in the file where processing should restart from either with a bookmark or remembering the line and column. (Be careful the user doesn't toggle the WordWrap as this may cause a problem).
The next thing is to possibly check a variable at the start of the code to know if you need to position the starting point and to possibly skip any processing that only has to be done once and, therefore, was already done if this is a restart.
Braces and Brackets in Wizard:
From the manual
When input fields are defined using the square bracket format, the Wizard is displayed before the first Clip instruction is executed/evaluated. The Wizard is built from all such fields encountered in the script. That is how and why you may see multiple input fields in a single Wizard as soon as you click on the Clip while others using curly braces may take a little while to pop up.
In other words, curly braces pop up as they are found in the code. Square brackets are put together and shown all at once when the code starts even if they are scattered throughout the code and not at the beginning.
Forgive me for lumping several topics together. I wouldn't have timeAs a programmer who has had to learn
many languages over the years, I hope I don't sound (fill in any one ofTrue. I think the problem is that one don't always understand fully what the rather terse explanations mean (don't get me wrong, I actually like terse). Then, when one reads again later it's crystal clear - because one now have learnt more and that helps one's understanding tremendously. But it's easy to think it isn't needed to read that basic stuff again.
The manual does stateDuh. Point proved and taken. ;-o)
A regexp way to replace the last comma in a string.This I like. It's good to show different ways to accomplish what's asked for. Maybe even more so when a RexEx solution is given to someone who doesn't do RexEx. That person won't be able to make changes to the code himself. I've always liked when both options are given.
Computer says no.
"joy8388608 via groups.io" wrote:
I hope I don't sound (fill in any one of several words)Helpful? Experienced? Absolutely right?
I am the one who used to (at the time when there still were handbooks)
unpack new gadgets only after having read and annotated the handbook in
full. After that I unpacked and assembled them, typed in all the settings I
had noted in the handbook in pencil and normally they worked first time.
When asked for help I'm known to demand the handbook first. "I don't know
where it is." "Find it! I'll not even look before I hold it in hand." (Yes,
I would look later, but don't pass that on, please.)
^!Prompt ^$StrReplace(",([^,]+)ZZZ";"\&$1";"^%axel%ZZZ";R)$Hey, that's great! I'll try to remember it. I'm with Lotta in "one should
strive for readability above all. That is more important than compactness
and even speed." but that idea of yours is not hard to understand -- at
least not after having someone else think of it.
In other words, curly braces pop up as they are found in the code.Yes, but: Only curly brackets evaluate functions and variables inside the
prompt. I frequently want to make my last entry the default for the next
time the input is asked for. Can't do that with square brackets. (And of
course you can't use square brackets in loops anyway.) On the plus side
they make code more legible:
is much easier than
at least when they're far apart in a long clip.
/¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --