Forum Replies Created
Okay, got it. Turns out that if you have to put a regex in a string, rather than entering it from a dialog, the compiler will interpret it using the different rules for single- and double-quoted strings. The easiest fix is to use single quotes, and double the alternation operator wherever it occurs in the expression, since there are potentially more characters to fix in a double-quoted string. The form of the regex I asked about that works is:
I think I collided with this because I was switching back and forth between the two string types, which confused me as to what was going on, since something different was failing in each. On top of that, there are a number of system functions or macros that “interpret” strings, and I was experimenting with all of them, as well as a couple that I wrote. The trick is to make sure that the regex arrives intact after whatever interpretation is going on. Thanks for the suggestions.
Here’s one example I’m working with. It’s a regex to find CMac functions. It’s a bit messier than the standard one in the REAlias list, but it will find some things that one won’t, and has fewer false positives. It’s a Perl expression (well, PCRE), and that’s all I work with since Dan faired PCRE in back in version 9.10. You can cut this down to just a simple alternation on two return types, and the problem is still there.
I haven’t tried
S_And_R(), on the grounds that it relies on
Find_Text()itself, although I have looked through it to see if it handles the input string in any special way. Looks to me, though, like the damage is done just by declaring the string. I’ve put debug dumps right after declaring the string, and they show nothing from the alternation position onward, so that the only match that could happen would be against the first alternative, and anything before that.
Okay, I’ve also found my original files, but they’re not small. Word Doc about 1.6 MB. Except that the pictures are much cleaner, it’s the same info as the web capture I mentioned above.
I’ve located a capture I did of the article I mentioned. I can upload it or e-mail it to whoever wants it. I’m still digging for my original source, but this will do as well for info. Believe me, it’s a lot easier to read than the source file comments. Let me know.
I’m many years out of the loop, but back when, I wrote a rather complete article for the Newsletter detailing exactly how the debug features in TTDBG (the additions written by Michel Vodika) worked. That article doesn’t appear to be on this version of the Forum, and I may not have a local copy anymore, but maybe Clay knows where to get it. If so, it may have Deley listed as author; that apparently happened when he took over editing things for MESI, as most things I’d done were changed to make him the official author at that time. You’ll know you’ve got the right article if the embedded screen shots use a pale cyan background and the code shown uses a peculiar box comment style that I favor.
As for single-step debugging, I don’t believe a Windows debugger was ever written, so, unfortunately, you can’t do that.
That answered a lot, and some is figured out. Some of my trouble came from only having a ME2006 manual for info. I guess 2008 doesn’t use a directory for tracking net id’s (that was the directory left empty).
There’s still one issue, though. The net client installer will create a subdirectory of the directory you pointed to using ME110_CFG_DIR, of the same name but with “.04” appended, and use it for the Config directory, not the one the variable pointed at. In any event, you’ll point at the wrong directory from then on. In spite of that, it still appears to work.
Thanks for the response, Clay.
Hey, Keymaster, Gatekeeper here. Long time no speak, Clay. If you could, would you contact me at my email? Having the Devil’s own time reaching anyone, and another long-time user in the same boat has resorted to contacting me. Throw me a lifeline, okay? Thanks.