On Sat, Mar 7, 2015 at 4:01 PM, Mike Bonner wrote:
> Ah k. Glad you found it. I had just wondered if the xp machine was slow
> enough to cause problems with the preopen, but as you say, when its called
> from a substack of the main, thats not the issue.
>
Now if I can only find a workaround .
Ah k. Glad you found it. I had just wondered if the xp machine was slow
enough to cause problems with the preopen, but as you say, when its called
from a substack of the main, thats not the issue.
On Sat, Mar 7, 2015 at 4:10 PM, Dr. Hawkins wrote:
> On Sat, Mar 7, 2015 at 2:16 PM, Mike Bonner
On Sat, Mar 7, 2015 at 2:16 PM, Mike Bonner wrote:
> If you move the code that causes the problem, from preopenstack to
> openstack, (or even opencard) does it start to work?
> If so, your preopenstack handler is trying to do things that require
> libraries that are not yet available.
>
The preP
If you move the code that causes the problem, from preopenstack to
openstack, (or even opencard) does it start to work?
If so, your preopenstack handler is trying to do things that require
libraries that are not yet available.
On Sat, Mar 7, 2015 at 2:09 PM, Dr. Hawkins wrote:
> On Sat, Mar 7, 2
On Sat, Mar 7, 2015 at 12:45 PM, Peter Haworth wrote:
> I see. Is there any error message displayed by the error handler?
>
It gives the line number of the stack, and name of the file.
Naturally, in an "OK" window that doesn't allow copying the text . .
An error occurred on line: 89
219,89,8 r
I see. Is there any error message displayed by the error handler?
On Sat, Mar 7, 2015 at 12:41 PM Dr. Hawkins wrote:
> On Sat, Mar 7, 2015 at 12:04 PM, Peter Haworth wrote:
>
> > So what ends up in PrefsDB? Not sure what you mean by "causes an error
> > rather than returning an error code".
>
On Sat, Mar 7, 2015 at 12:04 PM, Peter Haworth wrote:
> So what ends up in PrefsDB? Not sure what you mean by "causes an error
> rather than returning an error code".
>
Nothing; the line is never reached. It's an execution error, goes to the
execution error handler, and stops dead.
>
> Don't
So what ends up in PrefsDB? Not sure what you mean by "causes an error
rather than returning an error code".
Don't know if this might help, but I always check the db file exists (if
there is a file PrefsFilNam) before opening any sqlite database, just too
error prone without doing that.
On Sat,
I'm in odd waters at the moment, on XP (which is left over on a FreeBSD
laptop; I've never actually owned a windows machine, ever . . .)
Anyway, this application has compiled and run as a mac standalone for
years, and as a windows standalone compiled mac-side at some point in the
past.
I have a t
