XYplorer Beta Club

SammaySarkar wrote: I always get far better results using google.

Seems weird, but so true - I do the same on the ahk forum. Google outsmarts their own search engine when it comes to guessing my thoughts.

SammaySarkar wrote:just a note, I've not used exists() on the paper:-formatted path, but on the papername only, to check if it's not a <xypaper>-relative paper path.

I understand. And that's exactly the genius of it. Though it took me a while to figure it out, the "reverse" logic of it. To be honest, I still harbor some secret residue of doubt whether it's 100% foolproof (me again) to ALWAYS deliver the correct result. But that's the oddball not worth checking up on.

Hardest of all - and most sobering effect - is the realization that there is NO WAY I could have EVER come up with something like that myself. I mean this is as far out as - what's the name of that planet of yours? - pure sciene fiction. Free floating realms of thinking. Even those help text alienate me, I hold on to words for footing and grounding, and that's how I get stuck on active verbs like "converts (!) from relative to absolute path". I never dare that final jump beyond the physical aspect, in this case "converting" being used for comparison, not for actual conversion.

Scripting isn't that hard. It helps when you write it down in pseudo code / or logical steps and go step by step. The rest is translating it into real code. Visualize the input and the expected output!

what you have: paper:favorites
what you want: real path of this paperfolder

logic
1. get the name of the paper(folder)
-> possible scripting commands: gettoken / regexreplace / regexmatches

2. check if the name ("favorites") exists -> real path outside of <xypaper>
-> possible commands: exists / regexmatches (if it doesn't begin with [A-Z] or \\ (network path) it isn't the real folder)

3. you've either have the path after 2. or if it's <xypaper> resolve it
-> possible commands: eval / resolvepath

There is always more than one method to get the same result. The more you write code (and learn from other code examples) the easier it get's. Especially finding the right / best suited script commands.

A tip for your future code writing: avoid foreach / while loops when you have to go evtl. over thousands of entries. Try to replace it with regexmatches / regexreplace or evtl. formatlist (if possible)

there is NO WAY I could have EVER come up with something like that myself.

Stick to it, then you're in for more than a little smile when you read this quote of yours later.

<frank>
y'know, I'm not really as much of a wizard-of-logic as you might think. I still have to find my footing in all the languages I'm learning right now.
The main thing (well, in my XP) is to read the docs using exsamples ( ). Find some simple examples that you can relate to, read relevant reference, and try to figure out how it all fits together, then try something similar all by yourself. That's how I start out.
Speaking for myself, I always have this jolt of understanding, "Oh, THAT's how I can do it"! It's almost like a good kind of addiction. Once you get that, I don't know how you can stop yourself from learning more.
And another thing, don't think you can't come up with something better.
</frank>
Here's some motivation https://www.youtube.com/watch?v=E1oZhEIrer4

SammaySarkar wrote:just a note, I've not used exists() on the paper:-formatted path, but on the papername only, to check if it's not a <xypaper>-relative paper path.

Yes I see that now. You could have had a line like the following (last line) to determine if the paper folder existed, but in this scenario it's really not necessary because you are in a tab that should be pointing to a legitimate path (at least I would think so).In my situation with the Thumbnail script, I was determining if the paper folder referred to within the thumbnail cache file was legitimate or that it still existed...so I could delete it if not.

Thanks for the motivation, Sammay,
badly needed at times. That jolt of understanding - and also the occasional success - yes, you're right, highly addictive. But in a gambling sort of way. I am not yet at a stage where I feel in control, it's more like feeding the XY slot-machine with copy&paste coins, and sooner or later something is bound to come out of it.

@highend
As easy as 1-2-3. And it really is, when you get it explained and layed out like this. Afterwards, in retrospect. Math exercises used to be like that, you'd sit and fret and brood and wonder. And the solution turned out much simpler or much more complicated, but rarely matched the approach you had thought of.

What's missing in programming is the instant feedback you get from, say, hitting a wrong note in music, or making mistakes in cooking: You immediately know when and where and why you went wrong. If XY started to smell and cause smoke rising from the PC fan - yep, that would boost my learning curve.

highend wrote: A tip for your future code writing: avoid foreach / while loops when you have to go evtl. over thousands of entries. Try to replace it with regexmatches / regexreplace or evtl. formatlist (if possible)

Thanks. Pasted your advice into my private wiki. Must try to keep it in mind as well. It helps that you stick to it yourself, I remember seeing this approach in several threads. And every time I think "...heck, I really GOT to look this up", both the regex and the format(list)/replace constructs. And once in a while I do read the relevant help sections. Twice, and all over again, and once more, and then watch my mind go blank. New-age meditators would be jealous.

As easy as 1-2-3. And it really is, when you get it explained and layed out like this. Afterwards, in retrospect. Math exercises used to be like that, you'd sit and fret and brood and wonder. And the solution turned out much simpler or much more complicated, but rarely matched the approach you had thought of.

2 simple rules when you start to learn a scripting language:
- Get the big picture "what I want the code to do"
---> Break it down into as many single steps as possible (experience will teach you how to reduce these steps in the future)
The big picture looks complicated but all the little steps reduce complexity and let you solve the puzzle without getting confused (too much)

- KISS principle (keep it simple, stupid)
---> Don't try to solve everything in one line. Don't use (complicated) regexes when you still have problems with the easy ones. Don't try to solve something in an elegant way when you're in the beginning stage

I've read the scripting parts of the help file at least a hundred times (and I still do for sc commands that I need seldomly). I've started scripting with XY and I didn't had any experience before.

Learn from others: Read their code. It doesn't matter if you'd do it in the same way it's about trying to understand how a problem can be solved (and as you know there are multiple ways of achieving the same result). You'll develop your own way (your "style") of how to solve something. It comes automatically (but it takes time). If you're struggling with something in specific or a how to implement some kind of logic: Step away from the computer, get a paper sheet, write your current logic down, draw it. Check if it makes sense; if you can solve it with that. Get back to your computer, try again. It helps. At least this works for me. And when this fails, ask! We have enough experienced scripters on the forum...

Last tip: Get tools that help you. A good editor with syntax highlighting. Snippets that allow you to type less (and maybe have some hints which parameters are expected for a sc()). If you deal with regexes a good online resource or a local app. Make your life easier by not having to invent the wheel a second time.

What's missing in programming is the instant feedback you get from, say, hitting a wrong note in music, or making mistakes in cooking: You immediately know when and where and why you went wrong. If XY started to smell and cause smoke rising from the PC fan - yep, that would boost my learning curve.

Create a UDC that loads your testing script. Assign a keyboard shortcut to it. For me my UDC loads <xyscripts>\@Test.xys. Alt + x to invoke it. Just write a single / only a few lines of code. Execute it. Test it. Does it work as expected? If not, hunt the bug (step / unstep commands). If it works think about if you need to check the result of each command. When your small code block is perfect (at least from your current state of knowledge), continue with the next simple step.

Sometimes (better: in rare occasions) I receive a donation for a script that I post. I guess if they surpass the limit of ~50€ I'll order a good mic from amazon and make a few video tutorials about scripting (while showing how to solve problems / code things) In german of course! No, just kidding

Wow, thanks a ton, highend
very sound advice. Unexpectedly this thread turns into a veritable treasure trove, your guidelines would sit well in the scripting section, as a sticky topic.

Some things don't come easy to my personality type, such as stepping away from the computer. I get easily hung up on a problem, always thinking I am really close - it's gotta be this or that - almost there, just one more try ...

Other things I've been doing already, like calling my workbench script via UDC-shortcut. Saves time but just like step mode, the instant feedback cannot tell you why you failed - whether it was syntax, logic, wrong method - guess that only comes by with experience, knowing what to look for. Which assumes you're being aware of things like trailing spaces etc.

My main illusion was thinking of programming as " plain static knowledge" that you pick up like facts, like advanced operating instructions, details you know or don't know. I did NOT expect it to be a SKILL that gets better by practicing. Was not prepared for the multi-layered complexity, for the creative part, for the language part with heredoc dialects, for the fussy part with quotes and blanks, for external editors and RegEx tools, and definitely not for the amount of time you have to invest.

highend wrote: I've read the scripting parts of the help file at least a hundred times ... I've started scripting with XY and I didn't had any experience before.

That's the most motivating part of it all. VERY reassuring to hear that you and Ken are not holding PhDs in computer science who've been programming full time for 20 years. I was convinced of you guys scripting XY in an offhand manner along the way, like a concerto pianist throwing out an occasional encore.

Some things don't come easy to my personality type, such as stepping away from the computer. I get easily hung up on a problem, always thinking I am really close - it's gotta be this or that - almost there, just one more try ...

And that's the real reason why you can't get it working. Do you sometimes forget a name, e.g. "damn, what was the name of the guy in avatar" sam, sam... mh, can't remember. Do something different. The less you think about it, the earlier it comes to you. You're brain is trying to solve that riddle anyway "worthington"! That's his name...

Sometimes you need to view a problem (a programming problem) from a different angle, from a new perspective.

Other things I've been doing already, like calling my workbench script via UDC-shortcut

I use Sublime Text and my "build" script calls XY with the current script (and /flg=2) again with alt + x. So while I'm developing it I just press the same shortcut in ST which automatically switches to XY and executes my script in the editor.

the instant feedback cannot tell you why you failed - whether it was syntax, logic, wrong method

The debug window that you get when you use the step command shows you how what your line does, how a variable is resolved / changed, etc. Stepping through the code reveals logic errors. For example it's a valuable resource when it comes to quoting. Just use a step; right before a run / openwith command. You'll see what XY tries to execute and if the real quoting is correct or if something's missing / just plain wrong.

Which assumes you're being aware of things like trailing spaces etc.

Let your editor help you

I did NOT expect it to be a SKILL that gets better by practicing.

But it's exactly that. A skill. Write a hundred small scripts. For the next 100 you don't need any more documentation. All the small scripts help you to build a up a library of small code blocks that you can use in larger / more complicated scripts to solve all the small things you've had problems with before.

I was convinced of you guys scripting XY in an offhand manner along the way

I'm not far away from this. It's a whole lot easier now to put programming logic into real code. You know what tools you have, how to use them, etc. When I wrote a script that should compare two lists of files my first attempt was to use two foreach loops (inner and outer one) that would compare each line from one file with all lines from the second one. Yeah, this works. Sure. But it's slow as hell if you have hundreds / thousands of files. Now I do this with one while loop and regexmatch / replace which is the fastest way possible (at least inside XY; other languages have better ways to do such things efficiently). That's one of the reasons that I write some stuff in other languages than in XY itself. Speed. Some things are very easy and very fast in XY but because there is no threading you'll block XY while it's working. One of the reasons why Extractor was written in AHK. I'd need less code in XY to do the same (feature wise) but I can't work with it while it's running (at least not if I want to retain the "select a directory after the process has finished" and things like that).

A last note:
Many things look complicated at the beginning. For you one of the things is quoting. Over time you'll notice that you can solve it by a general rule. Use three double quotes at the beginning if you have any variables that need to be resolved or if you need command line parameters.
That works for run / openwith / runret commands. And you can use it for eval() as well.

An example: The first line uses a ternary conditional. Just a short form of an if - else construct. Less lines to use.
The second line uses a run command.
Three starting double quotes. The variable of $hstart, close it with two double quotes. Whenever you have to resolve a variable (<curitem> in this case), surround it by opening and closing two double quotes. At the end you have to end close it with the last double quote (because you started with three at the beginning).
Add a step command before the run line.
Execute the script. Look at what XY shows in the debug window (how it resolves the quotes). All items inside this run command are correctly quoted so that they can contain spaces in their paths.

More examples: Do you see how it works?

@ Stef:
You might find this useful: How did you start scripting?

A past shame (among many others):
http://www.xyplorer.com/xyfc/viewtopic. ... 017#p41712

Today:
Sometimes I *dream* solutions for some script problems. And I'm quite proud of some concepts I produced using XY scripting - not to mention the TIME I now save on almost anything computer-related. Keep going. It'll worth it. Word.

Hey Stef123, that's all you need is someone else piping in on this topic, but to me the most important thing is coming up with the idea of what you want to do. Is it new, unique, useful, can others also use it, etc. The idea, or big picture as highend called it, is it useful and worth spending your precious time on? If I have an good idea and with some limited scripting knowledge, it makes me want to script or code something. It becomes a challenge especially for me. I was an engineer but when I went to college, I didn't even have a calculator never mind a computer (they didn't exist). I know you've come up with great ideas. You've presented me with some of those for script additions or add-ons. That's the important part, the rest is just scripting that you'll pick up on rather quickly if you sit down and are motivated enough to make it work. Between the help file and great script tutorials/threads and the helpful people on this forum, there are plenty of places to look and find out how something is done - typically more than one way.

@Sky,
thanks for the encouragement and those links. Someone had pointed me there a few months back - might have been you, actually - and those guidelines really did string me along for a good while.

@Ken
thanks for sharing your background. Sounds familiar. I went to college in the Flintstones era when computers were only to be found aboard space ships. Computer-savvy claims were a clear sign that you had been abducted by aliens, or more likely, you escaped from the asylum.

I never expected to get into the nitty-gritty of such things. Had run my own business with a dozen employees who handled all tech details. Then my company tanked and I went through the bankruptcy motions. The IRS at my heels ever since, only allowing freelance consulting without any overhead, no offices, no emps. Trim and lean, one-man-show. Which also means I have to figure things out by myself these days.

klownboy wrote:The idea, or big picture as highend called it, is it useful and worth spending your precious time on?

My predicament exactly. Caught between high-flying visions and ground lessons, I spend hours in XY help and forums. Time has become the new bottleneck. I hate to waste it, it should yield maximum ROI. But it's just as difficult to make the right investment decision. Easy enough to think big, but impossible to shoulder it all by myself. I depend on "shareholders" who also believe in it and who chip in with considerable contributions to lift projects off the ground. THANKS for doing just that with Thumbs Maintenance.

The same loud THANK YOU shouts are going out to Sammay and Sky and highend and TheQwerty and FluxTorpedo and other purveyors of script luxuries.

highend wrote:
use a step; right before a run / openwith

Wow, all along I had this nagging feeling I am missing something here, and just now, after rereading several times, your advice finally dawns on me: "step;" - that's the catch, I had skimmed over it too fast, too many times. My idea of STEP had become stuck on what help seems to recommend: #750 (Step mode) and #752 (Try Script) - both of which require the tedious stepping through from the very beginning. And so I copied my code back and forth and introduced trailing spaces all over again. Anyway, now I finally connected the dots, another milestone - thanks

highend wrote:
I do this with one while loop and regexmatch / replace which is the fastest way possible (at least inside XY; other languages have better ways to do such things efficiently).

Ouch - that means I better be careful to not jump to conclusions for programming techniques in general. On the upside, it enabled me to tweak scripts provided by you and Sammay because they were AHK. They even look cleaner, almost no quotes, much easier to read and modify w/o all those brackets and parentheses.

highend wrote: because there is no threading you'll block XY while it's working. One of the reasons why Extractor was written in AHK.

This may explain why I never had problems using your Extractor script. Other ways of extracting with XY or via XYS behaved erratically at times, I could rely on it only when sticking around to watch it. (That was my impression, but I never dared to voice such ludicrous suspicions). With Extractor, however, I have no qualms handing over my stuff completely without supervising it. I can safely work on other things in the meantime.

highend wrote: ... general rule. Use three double quotes at the beginning if you have any variables that need to be resolved or if you need command line parameters.
... Do you see how it works?

Well, yes and no. A few months ago I was sure I had got the hang of it. But then those crazy quotes threw me off again. Here's an example - it works, but only after I removed the quotes from most parameters - just could not get it to work with the triple-quote approach:

Holidays, not much time...

Well, your code with the quotes brings up an XY scripting error - not working.
It's reassuring to see this happening to you as well. Confirms my suspicion that it's not just me, but that we are indeed dealing with crazy syntax rules - if only there was one, reliable enough to jot down for reference.

I also tried double quotes around all the parameters, and other variations, but nothing works, except my mixed quotes version. Don't know how I arrived at that, but I remember getting very frustrated that I couldn't not simply apply it to other circumstances as well,

Nothing urgent, enjoy your holidays.

Stef123 wrote:Well, your code with the quotes brings up an XY scripting error - not working.
It's reassuring to see this happening to you as well. Confirms my suspicion that it's not just me, but that we are indeed dealing with crazy syntax rules - if only there was one, reliable enough to jot down for reference.

The problem is probably that the program wasn't found. Do you have <xypath>\..\XnUtilities\NConvert\nconvert.exe?
Sorry, a blatant case of being context-insensitive.

The only rule for quotes is this, you have something in quotes: "Quoted". Now if you have to include another quote inside the quoted string, just double it: """Quoted with quotes"". Quoted with quotes."
It probably helps if you type both beginning and ending quotes at once, then go back into the quotes and type your string.
PRACTICE PRACTICE PRACTICE.

For curiosity sake more than anything since I'm not at all familiar with nConvert syntax, why are you using SC runret in this situation? Are you expecting a return as opposed to the image being converted? Why not SC run? Have you tried running those commands from a DOS command box? I'm more familiar with Image Magick or Irfanview command line options. I have some scripts doing conversions and cropping using both of those programs. Actually I just installed nConvert and saved the help to a text file to check out the options...seems powerful. Though I can't image anything for images being more powerful than Image Magick, but it's got some hairy syntax going on.

Edit: I've been playing around with nConvert's syntax a little and I've had much better success putting nconvert and it's parameters in a variable and then using SC run. For example this worked fine for me. Obviously you'd have to change the parameters and file/locations.