Re: Private constants in Eu 4.0
- Posted by RStowasser Jan 20, 2009
- 832 views
I would like to point to a problem using privat constants with Eu 4.0 (rev
[snip]
What is the difference if I use constants with integer instead of type int?
Interesting...do you happen to know the last version that worked? Most of the changes lately have been DEP related, so calling C-functions sets off a red flag for me (though as usual, it will probably turn out to be a red herring). I'll investigate deeper (though I'm not sure when, exactly, I'll be able to get to it). If possible, it would be a great help if you could reduce the failure to a minimal, independent test case.
Thanks again for the reports.
Matt
I was wrong with my assumption that the problem would be constants and global type. I think it is only a different behaviour of global type in Eu 3.1.1 and Eu 4.0
In the the gtk2 examples the code of hbox.gtk is:
... constant new = define_c_func(GTK, "gtk_hbox_new", {B, I}, P) ----------------------------- -- hbox() ----------------------------- global function hbox(boolean homogeneous, integer spacing) ----------------------------- return newInstance(c_func(new, {homogeneous, spacing})) end function -- hbox() ...
if I replace boolean with integer in hbox.gtk and vbox.gtk then arrows.exw of the EuGtk2 demos will run and some other demos also. boolean is the only global type in the Eugtk2 library and many examples break directly at this location. The code in globals.gtk is:
global type boolean(object x) -------------------------- return atom(x) and ((x = 0) or (x = 1)) end type -- boolean()
As this all works fine with Eu 3.1.1 I do not think that something is wrong with this. I suppose if I change the include statements of the Eugtk2 files to Eu 4.0 convention the remaining demos will run too. And I think that in win32lib this problem can occur in some special cases with type int also. But I am not convinced any more that it is because of using local constants.
Roland
