Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Ive used a ConText->spreadsheet->ResStore design cycle in all of my Nova development for many moons and never encountered any insurmountable difficulties until I tried to use ResStore with PICT resources for the first time. Im trying to do a mass RID renumbering of PICT resources in accordance with the ReadMe file that came with the ConText-ResStore utilties. The ConText dump of Nova PICT resources works as advertised, but when I attempt to run ResStore I consistently get:
Error Message = Resource File Error
This error always occurs on the very first PICT resource that ResStore trys to deal with. Ive made no changes to the PICT files themselves, they are the same identical files created by the ConText utility. Ive even tried making no changes whatsoever to anything, just run ConText dump and then immediately run ResStore -- same error message. I really dont want to manually renumber a couple of hundred PICT resources. This brings me to ask two questions:
1. Is there anything I can do to get past this error or is there an updated version of ResStore (I have v 1.0.0) ?
2. Is there some other way to accomplish a mass renumbering of Nova PICT resources?
Thanks in advance for any help.
------------------ . - lost in the ozone again - .
Quote
Originally posted by Arturo: **1. Is there anything I can do to get past this error or is there an updated version of ResStore (I have v 1.0.0) ?
2. Is there some other way to accomplish a mass renumbering of Nova PICT resources?**
By hand. I must admit, I didn't even know ResStore could handle PICT resources. We never tried to get it to do anything other than text based resource management.
Dave
And the answer is...
Preface to the answer- When you run ConText on an external resource such as a PICT, rlë8/D, or snd, the utility creates two kinds of files; 1) a ConText.txt listing file that contains normal resource data like the type (PICT), the RID, the resource name, the source file name, plus a filename that references the external resource file; 2) a group of files containing one external resource in each file. The external resource filenames generated by ConText are of the form NNNNN_RSRC.<name>, where NNNNN is the RID of the parent resource listed in the ConText.txt file, RSRC is the type of external resource, and <name> is the parent resource name. My ConText generated list of files looks like this:
03000_PICT.name1 03001_PICT.name2 ...etc. 03099_PICT.name100 ConText.txt
Ive often found that a good way to solve computer related problems is to try and think like a computer:
CPU step 1 - Human tells me to ResStore this folder full of files. CPU step 2 - Look at the first file but find no standard ConText file format references (because its a PICTure). CPU step 3 - Fatal error out, telling my human that I was given bad data.
Aha! Maybe ResStore needs to see the ConText.txt file FIRST, so that it knows what to do with all of those PICT files. So I rename the ConText.txt file to 00ConText.txt so that it appears first alphabetically and rerun ResStore.
Voila -- it works. Another undocumented feature is discovered.
I kinda love the way you make your computer think (tell my human...). Actually, as this method comes from what you say you are in our "Who's who" topic, I must be a pretty darn good method. Computers are not mysterious, they just do things their (odd but desperately logic) way.
------------------ M'enfin! Y'a personne qui parle français ici? Suport the ß! Replace all your ss's by ß's!
While I may have overdone the anthropomorphization a bit in this instance, the technique is indeed very viable. It is an especially useful method for troubleshooting coding errors, given that most compiler error messages are cryptic to the point of being useless (eg. see above), other than flagging the existence of some kind of problem. If thinking like a CPU is done correctly, one is forced to be be very literal in the interpretation of whatever programming language is being dealt with. And oft times this results in reading the code with a much more objective perspective, rather than the usual egocentric I-didnt-make-a-mistake,-the-computer-did point of view.
Of course. I completely agree. That's the whole problem with compiler errors: the computer is not supposed to know waht we want to do, he just does know it misses something to make him compile it. I've experienced it sometimes.
The less obvious "error" I've ever experienced when programming is the following one: trying to make a little program in BASIC on my sturdy TI-89, on execution the program made one loop, one another, but not a third one. I checked for spelling, syntax, etc... applied my own reasoning similar to your one ("actually, now it is there, is the "if" condition is true, it should go there, etc..."). Nothing.
After many different rewritings of the program I found out that, if you use a GOTO inside a statements list to be done of an IF control structure, at the arrival it believes it is still in the statement list to be done of the IF control structure! It was the hardest to spot source of a problem I've ever found (but still is nothing compared to the "lack of memory" error that can be caused in EV by a faulty spďn ressource).