IonicWind Software

I recently completed a 10,000+ line program using ebasic. I stuck with ebasic during development as it was stable and did what I needed. I always planned to buy IWbasic to support its development, so tonight I downloaded the trial copy and tried to compile this program that gives no errors or warnings in ebasic. The outcome was 134 warnings and 3 errors and a failed compile. Before I spend time tracking each one down, thought I'd ask if there are some simple differences I should look at. If I get this working, I'll convert the trial to a purchase.

1. 30 of the warnings were to unreferenced variables and subroutines. Those are fine since I purposely have a second program embedded in the first and those portions are commented out.

2. A bunch of warnings related to dialogs and windows. Every window got a warning message of the form: Warning: Argument 9 (main) does not match the declaration of IWBWNDPROC. Different return type: none, should be int. Every dialog got a similar message: Warning: Argument 9 (handler_printsetup) does not match the declaration of IWBDLGPROC. Different return type: none, should be int.

3. Most of the rest dealt with file read and write operations where a user-defined type was the variable. For example, got "Warning: 'bezsegments' is not an array" for the following line:       read myfile,tblock.bezsegments

where earlier in that file i defined extern tblock[21]:ring

type ring
   def bezsegments:int
   def bezdotnum:int
   def crossbezsegments:int
   def crossbezdotnum:int
   def crosssectionnum:int
   def pos[3,2,7]:ry
endtype

type ry
   def r[2]:float
   def y[2]:float
   def h:float
endtype

All the variables except the pos[3,2,7]:ry throw the same warning (but see #4 below). This happens to two user-defined types, only for the int variables, and only for the read/write operations. These same types are used in many lines throughout the program and get no warning. All the other read/write operations without user-define types have no warnings.

4. The 3 warnings come from another file in the project than the errors in #3 above. They are:

Error: SIZEOF: unsupported operation
Error: FUNCTION (__READ): invalid type in parameter 3 (typeOpr)
   for code: read myfile,pblock[0,i].pos[j,k,l].r[1]

Error: FUNCTION (__READ): invalid type in parameter 3 (typeOpr)
   for code:    read myfile,pblock[1,i].pos[j,k,l].r[1]

But it's the same user-defined type as in #3, in a read operation, but this time it's not the int variables but the pos variable that gets flagged.

I know the code snippets aren't much. I can add more but I'm thinking there may be a simple explanation for why iwbasic flags these items and not ebasic.

Thanks for any guidance, Rich

Quote2. A bunch of warnings related to dialogs and windows. Every window got a warning message of the form: Warning: Argument 9 (main) does not match the declaration of IWBWNDPROC. Different return type: none, should be int. Every dialog got a similar message: Warning: Argument 9 (handler_printsetup) does not match the declaration of IWBDLGPROC. Different return type: none, should be int.

To get rid of those warnings you:
1.change every message handler subroutine from this
sub handler
to sub handler(),int
2. then in every message handler routine
change this
return
to this return 0
=====================================
you said you defined this
tblock[21]:ring
which IS an array
and then you did this
read myfile,tblock.bezsegments
which is NOT an array element
this would be an array element
read myfile,tblock[0].bezsegments

I need to see the declaration for
pblock

I might be able to help you faster if you email me a copy of the ebasic source and let me try to compile it and see what is going on.  I do that on regular basis; I don't 'steal' people's code and I toss it after the issues are resolved.

Thanks for the quick response Larry. Let me make the changes you suggest and comment out the unreferenced variables so the number of warnings are fewer before sending you a copy.

Rich

It's now compiling and running. Mostly was your #1 and #2 suggestions and commenting out one subroutine which I need to examine. I'll send the file if I can't figure it out.

Another quick question Larry, for my education: why do the handler sub routines require the return value? That's different than ebasic (or at least ebasic didn't require them) and in the IWBasic user guide, I didn't see the examples use them. Thanks, Rich

Quote from: RG on October 28, 2014, 11:36:08 AM
Another quick question Larry, for my education: why do the handler sub routines require the return value? That's different than ebasic (or at least ebasic didn't require them) and in the IWBasic user guide, I didn't see the examples use them. Thanks, Rich

Prior to IWBasic the return 0 was being taken care of and hidden by the compiler
When Sapero was going through and cleaning up the code prior to the release of 2.0 he found that hiding the return value was causing problems with his optimization and was in a "rat's nest" of code.  The resulting fix required that the user's code be modified.
As for the help file, I'm still going through it and updating it.

Thanks for the explanation. It's a great help to have you around.

Quote from: RG on October 28, 2014, 12:11:15 PM
Thanks for the explanation. It's a great help to have you around.

Thanks.
Right now the new help file has about 300 pages more than the 'official' release version.