OBloodyHell

No, I've got an issue with bad interface design. Supposedly, I do have the full version installed. I can't tell, since there's no sign of any difference between the two, if it is, and it didn't produce any error message on the install, if it isn't. There is, in the autoit menu directory, a program named SciTE Script Editor and an SciTE menu directory in which there is a program named SciTE The "about" of the former says: SciTE Version 3.2.0 Jun 9 2012 00:35:28 The "about" of the latter says: SciTE Version 3.2.0 Jun 9 2012 00:35:28 Maybe they're both the same thing, but I'm pretty sure the former was there before I installed it, and the latter was there after... but either the "small" version was replaced by the install or the two have the same "about"... if it's the latter, that's rather obvious bad design. This: is egregiously bad interface design. It should be GREYED OUT, "disabled" as a menu option, it shouldn't be "disappeared". And yes, that was at least partly the source of the problem. Once named, a whole host of options formerly nonexistant became visible... And yes, I maintain that is seriously BAD design. Menus should be consistently displayed. If an option is not available, it should be disabled/greyed, not disappeared so someone has no idea what it is or where it is when they are learning the program. I just spent an hour of my time utterly wasted trying to find out where something was, that I knew had to exist, because of this misfeature. Now, as a secondary consideration, it's really ridiculous to require the file be named before you have access to half the functions of the program. If you want to exercise that kind of control, just insist that files be named up front before you even open an edit window. Start with "closed" program entry. It's very atypical behavior for pretty much any program. Either "new" should require you to enter a file name to proceed, or it shouldn't be requiring restrictive function except on execution itself... which should be greyed out, not "disappeared" as an option. And "record" certainly has no reason to be excluded, if you aren't going to do that, it's installing/writing code, not executing it. P.S., I've been programming and coding interfaces for 30+ years, so I've got my programming chops to make comments on interface design weaknesses. If there are reasons for doing some things this way (i.e., don't do things unless there is a name to the script) then just NAME the script in the first place, and don't allow unnamed scripts to even exist.

Ya, is why I would alter it to make it more generic. But the basic function is pretty trivial, so it's silly to have to code that part by hand when it's so straightforward. Why the hell is Au3recorder not a menu function under tools? That seems ridiculously obvious. Note: It's not doing a damned thing when I hit alt-F6. Not a thing. Another reason something like this should be a MENU option. SciTE Version 3.2.0 Jun 9 2012 00:35:28

I used Auto-IT years ago... isn't there some kind of script recorder? I looked for it but couldn't find it. The task I have in mind lends itself to mostly recorded scripts with a few tweaks here and there in the final script to make it more generic.

LOL, ya, the old structured programming days.... Your instructor never got over the switch to event driven coding, since it's obvious to me that many coders ignore the whole idea of avoiding "go tos", which is generally what a throw/catch pair is. Current event driven coding ignores black boxing entirely, since you can never really tell when an event is going to steal focus anyway, making a black box impossible. The real problem is when you get an event-driven coder operating on a procedural environment like SQL, which is a defacto procedural language with some event gew-gaws thrown in... The event coder will be determined to ignore all structural coding rules and code like SQL was event driven, leading to defacto spaghetti code even when the problem doesn't need it. Hint: Avoid Throw/Catch scenarios in SQL. Structured programming, however, is like anything else -- it can be taken by someone, and they can just run straight off the end of the earth with it. Anyone who knows the old language APL knows that the prime goal of an APL program is to fit it on a single line. THAT, in APL, is considered "elegant". It's a unique language with a very unique set of goals and qualities (SNOBAL is the only other language I found quite as impressive... and in SNOBAL, recursion isn't a function, it's inherent in the DESIGN). That didn't stop some idiot from writing a book titled "Structured Programming Techniques In APL".... written by someone who needed a few headbashings with a cluebat. You should avoid self-modifying code as much as possible, and yes, you should use structured programming techniques when they make sense, but my own experience writing code is that it's quite possible to use a GOTO far more clearly than a complexly interweaved structural construct sometimes. In general, you shouldn't have more than a single goto or two, tops, in any given 100 lines or more of code, or a single function, whichever is smaller, and even there, it's pushing it. Recursion is a powerful tool when used correctly. Most problems it is "correctly" applied to are pretty self-evident, in that they naturally define themselves quickly and easily as a recursive routine. Parsing a line of text or breaking it into a BNF grammar can be such a thing -- Hence my earlier comment about SNOBOL. SNOBOL was designed with text processing (interpreting a computer language) in mind.

Recursion is a remarkably powerful tool that can simplify certain types of coding, at the cost of potentially notable overhead. The classic example of an easy thing to code recursively is the Factorial function, F(n)= n*F(n-1) 1) You have to be careful you properly code for an end, or the code will run on infinitely until terminated or it causes a resource crash 2) It has to have a finite end, duh. 3) It can be a resource hog, as each iteration of the recursion usually takes a lot of time and setup to save the prior state when calling the new state. Hence, placing a deep recursion that calls itself 1000 times in a loop that runs 100,000 times can be a bit of a bear. 4) Often there is a lot of trash collection overhead, too, as usually it's implemented that allocations are made for each call, and then released, often fairly often and quickly. Recursion is usually best when you can define the recursive function inclusively as a single function... if it calls other routines a lot, or is a huge, 1000-line code blort, then it's probably better to look if an iterative system will work. The more complex the termination conditions are, the better an iterative solution is likely to be. ==== P.S., Long ago, in a bygone era, I implemented a recursive algorithm in Fortran 77 .... which did not support recursion. I did it, yes, as you'd expect: by simulating the recursion using iteration.