Just thought I'd make a bit of noise about a previous post of mine that seems to have fallen through the cracks… ("Problems with RECORD property," some time in July, in case the HREF gets broken)

If I'm doing something completely unsupportable, I'd appreciate it if someone would just tell me… Otherwise, I'm at a loss here, and could use a few ideas. I could send an OIWINEXE record, but there is a LOT of supporting code so it wouldn't be runnable without significant effort.

Waiting in hope ;),

[email protected]

Alex,

Have you saved off your generated record and compared it to a similar OI gen'd record? What, if any, are the differences?

dsig

David Tod Sigafoos ~ SigSolutions

[email protected]

DSig,

That's one of the first things I looked at… I've compared two OIWINEXEs and have not yet found any significant differences. As I said, I've already tried overriding all my GOT- and LOSTFOCUS events (so that they only 'return 1') but it's made no difference.

-Alex-

Alex,

There is no easy way for us to determine what is not working. You have a couple of possible ways to resolve this:

1) If you just happen to be in the Boston area sometime, we could take a look at your system (i.e. bring it on a notebook)

2) You could mail us your system (don't laugh but people have sent us entire computers to reproduce specific issues … in your case, a CD or ZIP disk should do fine)

I'm not sure what other ways we could help. Your issue doesn't fall into the realm of the problems that our tech support staff and Q/A groups work with.

Cameron Purdy

Revelation Software

Cameron,

I've zipped up our OI 3.61 development system, and all the files it needs, plus a minimal database… It's 17 MB. I could e-mail it to you, or put it up on a WWW/FTP site, either as one 17MB file, or 13 1.44MB ones, at your convenience.

I'm almost certain that the problem lies in some quirk of our OIWINEXEs that the OI default LOSTFOCUS event isn't expecting.

Oh, and as an added bonus, this copy of the system exhibits a bug I've seen a few times, in which REVDEBUG.DLL GPF's at 0003:0000301b, at an odd place in a routine which doesn't even contain a DEBUG statement. I've narrowed the GPF down to a single subroutine call… I can't trace into it or over it. If I remove the debug statement from the routine in question altogether, I get the same GPF, presumably in the same place.

Thanks for your time,

Alex.

Alex,

David Carrano from our tech services group will be contacting you regarding getting your application set up here.

Thanks,

Cameron Purdy

Revelation Software

View this thread on the Works forum...