Announcement

**Clay Clear** · 10 Jul 2001, 04:21 PM

Mike,

You can't have SUB's & FUNCTION's nested within other ones.
Instead, maybe try using a GOSUB within the Callback?

Regards,

------------------
Clay C. Clear

http://www.v3space.com/a/a39/202/

[email protected]

**Lance Edmonds** · 10 Jul 2001, 04:59 PM

Clay, I don't believe Mike is nesting them within one another, as the compiler would not compile such code. I believe he means the sub is called from a callback.

Mike, the problem you describe sounds more like something else in your code (most probably within the callback) is adjusting the value of the global variable - callbacks are reenterant so static and global variables can be changed by "simultaneous" execution. I would be VERY surprised if MSGBOX itself was the cause of the problem.

In order to help you further with this problem, you are going to have to post a suitable compilable example file that we can take a look at.

Thanks!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Mike Jenkins** · 10 Jul 2001, 10:54 PM

Originally posted by Lance Edmonds:
Clay, I don't believe Mike is nesting them within one another,
as the compiler would not compile such code. I believe he means
the sub is called from a callback.

Mike, the problem you describe sounds more like something else
in your code (most probably within the callback) is
adjusting the value of the global variable - callbacks are
reenterant so static and global variables can be changed by
"simultaneous" execution. I would be VERY surprised
if MSGBOX itself was the cause of the problem.

In order to help you further with this problem, you are going
to have to post a suitable compilable example file that we can
take a look at.
[/B]

Right, Lance, by "nesting" I meant I was calling the SUB in
question through a chain of 2 or 3 other SUBs, and when I kept
having the problem, I tried shortcutting that by creating a
"test button" and directly calling the problem SUB from the
button callback, which behaved in the same manner, so that was
not a solution.

I've been studying the code all day, trying to find a flaw, and
finally went ahead and created a separate .EXE that consisted
solely of the problem SUB and a couple of SUBS it calls, fed it
the same test data that was busting it in my full program, and
voila! It works fine. A real mystery, but at least I found
a way to kludge around it. Probably some obscure problem
elsewhere in my program, that for some reason is only screwing
up this one SUB.

I could send you the source code of the small .EXE to take a look
at, as you suggested, but since it seems to work perfectly, as
part of the small program, I don't know how you could reproduce
the problem.

Strangely, the SUB even works OK in the large program, if I
remove the MSGBOXes, but generates the errors described as soon
as I add back even one MSGBOX. I've split it into two SUBs now,
but it still malfunctions when it hits a MSGBOX on the way thru
(in the large, full program).

Thanks, anyhow, but I think I've simply hit the wall on the size
of my program, so all remaining features (and as much as possible
of the existing code) will have to be moved into subsidiary .EXEs
or, if I can figure out how, into DLLs.

Dumb question on DLLs: The docs make it sound real easy to do a
DLL-just write the functions, add "EXPORT" where appropriate,
and compile as a .DLL. But the docs only mention how to call a
DLL from VBasic, and not how to get a PB .EXE or other .DLL
to call a function in the .DLL. So I haven't a clue as to
whether the .DLL file needs a PBMAIN or WINMAIN function, etc.,
or just the utility functions themselves.

------------------

[This message has been edited by Mike Jenkins (edited July 11, 2001).]

**Lance Edmonds** · 10 Jul 2001, 11:29 PM

DLL's use a LIBMAIN, DLLMAIN or PBLIBMAIN function (the DLL equivalent of PBMAIN/WINMAIN in and EXE). However, unless you need to do initialization when the DLL loads, you can omit the LIBMAIN/DLLMAIN/PBLIBMAIN and PowerBASIC will put one in the final compiled code for you.

One thing to be aware of if you do create such a function yourself, is that the function MUST return non-zero or the DLL will not be loaded, and Windows will not be able run your application at all.

Basically, you declare DLL functions in the same general manner as you would do with VB (except you don't need to worry about the VB string issues! ). ALso take a look at the declarations in the WIN32API.INC file set for more examples of declarations for DLL Subs/Functions.

The following is a very basic DLL and EXE example (off the top of my head, untested):

Code:

' DLL code
#COMPILE DLL "MYDLL.DLL"
FUNCTION MyFunction ALIAS "MyFunction" (BYVAL x AS LONG) EXPORT AS LONG
  FUNCTION = x * 2
END FUNCTION
 
 
' EXE code
#COMPILE EXE
DECLARE FUNCTION MyFunction LIB "MYDLL.DLL" ALIAS "MyFunction" (BYVAL x AS LONG) AS LONG
FUNCTION PBMAIN
  DIM z AS LONG
  z = 100&
  MSGBOX STR$(MyFunction(z))
END FUNCTION

Simple, eh?

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Bern Ertl** · 11 Jul 2001, 07:04 AM

Mike,

I would like to reiterate that you should check all your array
assignment code. I had a similar problem a while back. I was
assigning data outside of the array bounds and no errors were
being generated.

At least, no errors were generated until the OLE string engine was
used. At that time I would get Error 9s. I suspect that you are
referencing invalid array subscripts somewhere/time before your
MSGBOX code generates the error.

------------------
Bernard Ertl

**Russ Srole** · 11 Jul 2001, 09:48 AM

Mike,

There's a dll example in the sample folder. It is perfect as a
template. With that dlls are a breeze.

Russ Srole

------------------

**Mike Jenkins** · 11 Jul 2001, 12:20 PM

Aha. Thanks, Lance, that looks pretty straightforward, and
thanks for pointing out the non-zero return issue, which I would
have probably run into and been made crazy by...

Also, Bern, I'm afraid you may have hit the nail on the head,
if out-of-bounds errors aren't always caught by the error traps I've
put in all but the simplest SUBs/FUNCTIONs. I've found quite a
few places where my code was allowing invalid subscripts in
arrays, which WERE trapped by the error code, but if they are not
all detected, that could well be causing the odd behavior with
the MSGBOXes I've encountered, at least where I try to use them
in fairly large SUBs.

I should point out that I created some real havoc and crashed
my program when I erroneously used a MSGBOX function and left
out the %MB_YESNO (while using %MB_SYSTEMMODALYESNO style),
which wasn't picked up as a syntax error, but apparently caused
fatal problems till I corrected it. (This was in the same SUB
where I've been unable to get the MSGBOX to work, even in the
simplest MSGBOX X$ form, without turning global values accessed
in that SUB to zero.)

------------------

[This message has been edited by Mike Jenkins (edited July 11, 2001).]

**Mike Jenkins** · 11 Jul 2001, 12:37 PM

Originally posted by Russ Srole:
Mike,

There's a dll example in the sample folder. It is perfect as a
template. With that dlls are a breeze.

Russ Srole

Yes, Russ, I looked at that last night, and was wondering
if that was a "skeleton" I could simply add my FUNCTIONs into,
and be up and running? Guess I'll try it with a simple SUB or
FUNCTION and see if it works.

Lance seemed to suggest in his post (see above) that it's also
possible to just compile the FUNCTIONS/SUBS alone, w/o a LIBMAIN
FUNCTION or the like, as a DLL.

Do I understand that correctly? (But I assume that I'd at least
need to add an #INCLUDE for the Win32API, and a #COMPILE DLL
statement, too, of course.)

This may not be as complex a task as I thought it was....
Thanks for the guidance.

------------------

**Mike Jenkins** · 11 Jul 2001, 01:14 PM

Originally posted by Lance Edmonds:
DLL's use a LIBMAIN, DLLMAIN or PBLIBMAIN function (the DLL equivalent of PBMAIN/WINMAIN in and EXE). However, unless you need to do initialization when the DLL loads, you can omit the LIBMAIN/DLLMAIN/PBLIBMAIN and PowerBASIC will put one in the final compiled code for you.

One thing to be aware of if you do create such a function yourself, is that the function MUST return non-zero or the DLL will not be loaded, and Windows will not be able run your application at all.

Basically, you declare DLL functions in the same general manner as you would do with VB (except you don't need to worry about the VB string issues! ). ALso take a look at the declarations in the WIN32API.INC file set for more examples of declarations for DLL Subs/Functions.

The following is a very basic DLL and EXE example (off the top of my head, untested):
[CODE]
' DLL code
#COMPILE DLL "MYDLL.DLL"
FUNCTION MyFunction ALIAS "MyFunction" (BYVAL x AS LONG) EXPORT AS LONG
FUNCTION = x * 2
END FUNCTION

....

Simple, eh?

Lance, sorry to keep asking dumb questions, but is there a
different set of syntax rules for DLLs? I tried compiling
the above simple DLL and couldn't get past a "Syntax error"
message for FUNCTION=X * 2. (I also tried it as simply
FUNCTION=x or FUNCTION=1 (or 1&) and still got syntax error
messages.)

Is the FUNCTION statement not allowed in DLL's?

Or is my compiler out of whack? I use statements like FUNCTION=1
in my EXE code all the time, and never got dinged for a syntax
error before on that one....

------------------

**Eric Pearson** · 11 Jul 2001, 02:10 PM

Mike --

That code compiles fine for me! Did you paste it directly from the BBS, or did you re-type it?

What column is the error reported for?

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected]sync.com [email protected]</A>

[This message has been edited by Eric Pearson (edited July 11, 2001).]

**Russ Srole** · 11 Jul 2001, 08:06 PM

Mike,

I use the dll sample as a skeleton and just go from there.
I really don't if you need the libmain or not, but since the folks
at PB provided a sample I just use it and it works. Copy and
paste is a wonderfull thing.

The statement "Function = x" is perfectly legal in a dll. I don't
see that there are any real differences between a dll and an exe,
except you have to start a dll with an exe. I wrote myself a little
program that looks through the specified dll and creates declare
statements for any sub or function that is exported. That has
made life a lot easier. I'd post it, but as written you have to
have Ez_Gui. If enough folks want it, I'll redo it in ddt (with
Ez_gui freeware) & post it.

Russ Srole
that

------------------

**Mike Jenkins** · 11 Jul 2001, 08:28 PM

Originally posted by Eric Pearson:
Mike --

That code compiles fine for me! Did you paste it directly from
the BBS, or did you re-type it?

What column is the error reported for?

-- Eric

Thanks, Lance, that was the problem -- I had cut & pasted it,
and despite deleting the "syntax error" line several times and
retyping it, there must have been some high-ASCII characters
still in there, somehow, causing the glitch. The "ghost en
machina."

It works! Cool, and thanks much! Now I've got something to
work on again.

------------------

**Mike Jenkins** · 11 Jul 2001, 09:17 PM

Originally posted by Russ Srole:
Mike,

I wrote myself a little
program that looks through the specified dll and creates declare
statements for any sub or function that is exported. That has
made life a lot easier. I'd post it, but as written you have to
have Ez_Gui. If enough folks want it, I'll redo it in ddt (with
Ez_gui freeware) & post it.

Russ Srole

Cool. Sounds like a great little labor-saving utility, for a
fairly onerous chore, especially if you've got hundreds of SUBs
and FUNCTIONs, especially. Hope you'll post it -- I'm another
EZ-GUI user.

------------------

**Russ Srole** · 12 Jul 2001, 05:44 AM

Mike,

In that case post your email address & I'll pull out my registration
number & some other buttons that are specific to my projects &
I'll send you the source code.

Russ Srole

------------------

**Mike Jenkins** · 12 Jul 2001, 08:47 PM

Originally posted by Russ Srole:
Mike,

In that case post your email address & I'll pull out my registration
number & some other buttons that are specific to my projects &
I'll send you the source code.

Russ Srole

Thanks, Russ, would be much appreciated. E-mail: [email protected]

-- Mike

P.S. -- Let me know your e-mail if you'd like a complimentary
copy of my Wall Street Raider (the program I'm finally porting
to Windows, after 15 years of selling the DOS version) when I go
to market with it. (Should that blessed day ever arrive.)

------------------

**Mike Jenkins** · 15 Jul 2001, 02:29 PM

Originally posted by Bern Ertl:
Mike,

I would like to reiterate that you should check all your array
assignment code. I had a similar problem a while back. I was
assigning data outside of the array bounds and no errors were
being generated.

At least, no errors were generated until the OLE string engine was
used. At that time I would get Error 9s. I suspect that you are
referencing invalid array subscripts somewhere/time before your
MSGBOX code generates the error.

Hmm... Scary. Even if I turn #DEBUG ERROR OFF I still get
no error problems (no Invalid Page Faults, etc.) in my app,
until I click on the button that calls the errant procedure that
contains the MSGBOX culprit. Do you recall if you were able to
run without (apparent) errors in your app, despite out-of-bounds
errors, even with #DEBUG ERROR OFF? (I thought Windows would
crash the program in that case.)

------------------

**Lance Edmonds** · 15 Jul 2001, 08:42 PM

Windows will only GPF your app if it accesses memory not allocated to the app. Depending on what other variables aare stored at the end of the array, you may just overwrite them (causing a corruption), but not actually access memory that does not belong to your app.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Bern Ertl** · 16 Jul 2001, 06:06 AM

As Lance just stated, this is a very tricky bug to quash.

The 'runtime' will not identify the out of bounds subscript if
the memory space is owned by your app. I did not discover the
problem in my own code until I started visually tracing through
my code backwards from the error point until I saw the problem.

If you are referencing arrays with expressions as the subscripts,
you might add a few MSGBOXs to display the expression value as
well as the LBOUND & UBOUND for your arrays.

It might be possible to trace this with the debugger too, but
I've never used it. I'm used to using my own internal debugger....

------------------
Bernard Ertl

**Mike Jenkins** · 17 Jul 2001, 08:47 AM

Originally posted by Lance Edmonds:
Windows will only GPF your app if it accesses memory not
allocated to the app. Depending on what other variables are
stored at the end of the array, you may just overwrite them
(causing a corruption), but not actually access memory that
does not belong to your app.

Thanks, Lance, I didn't realize that. In any case, haven't
had any GPF's since I started developing the current app.
However, it does seem that if I turn off debug error trapping,
and (deliberately or otherwise) try to use an array variable
with an out of bounds subscript, the program immediately
crashes -- not with a GPF, but with a Win 98 "Invalid Page Fault"
error. I discovered that last week, when I first tried to
run the program with #DEBUG ERROR OFF, and it kept crashing when
I clicked on a certain button. I got an instant crash every
time, till I found the SUB with an obvious weakness in code.

Now it no longer crashes at any point in the program, with error
checking off, so I was thinking (hoping?) that means I'm no
longer producing any out of bounds errors. Not necessarily so?

------------------

[This message has been edited by Mike Jenkins (edited July 17, 2001).]

Announcement

Message Box Problem

Message Box Problem

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment