1. NO!!!!
What have you DONE to Win32lib?!?!?! Look at that code! It looks like
someone shrouded...no, scrambled the code and tried to put it back
together! In my entire life, I have not SEEN such bad style! Have you
considered how this will affect debugging? Maybe you don't want us
debugging YOUR messed up code! This library is incompatible with
earlier versions. You've already gone too far. Now others are using
this ABOMINATION of David Cuny's original! How COULD you???
2. Re: NO!!!!
That`ll learn you that it is better to code in C++ .
Ferdinand Greyling(Duke Fungus)
----- Original Message -----
From: sephiroth _ <euman2376 at yahoo.com>
To: <EUforum at topica.com>
Sent: Wednesday, February 07, 2001 8:09 PM
Subject: NO!!!!
> What have you DONE to Win32lib?!?!?! Look at that code! It looks like
> someone shrouded...no, scrambled the code and tried to put it back
> together! In my entire life, I have not SEEN such bad style! Have you
> considered how this will affect debugging? Maybe you don't want us
> debugging YOUR messed up code! This library is incompatible with
> earlier versions. You've already gone too far. Now others are using
> this ABOMINATION of David Cuny's original! How COULD you???
>
3. Re: NO!!!!
> What have you DONE to Win32lib?!?!?! Look at that code! It looks like
> someone shrouded...no, scrambled the code and tried to put it back
> together! ...
hehe.. come on, Derek is trying. But yes, i've seen that too.
I find that keeping things simple as possible is
the best programming style.
Don't complicate if you don't need to 
4. Re: NO!!!!
Hi Everyone,
I'd be more than happy to take ideas and submissions for Euphoria Coding
Standards. I'm trying to put one together right now for use with Win32lib
but the ESL could use it too.
----- Original Message -----
From: "sephiroth _" <euman2376 at yahoo.com>
> What have you DONE to Win32lib?!?!?! Look at that code! It looks like
> someone shrouded...no, scrambled the code and tried to put it back
> together!
Thank you - I tried very hard to make it obscure.
Not really. I wrote a utility (eucompress.exw) that takes any euphoria file
and tries to reduce its size by stripping comments and unrequired
whitespace. If I can be bothered, I'll go the next step and remove
unrequired linefeeds too. I was going to rename identifiers to smaller ones
but debugging would then be just too hard.
The real code is in win32lib_full.ew. This contains better whitespace usage
and comments and the library documentation.
> In my entire life, I have not SEEN such bad style!
Still new to programming then are you? 
> This library is incompatible with earlier versions.
So? No one promised compatibility, in fact, until v1.0 we are warning people
that there are going to be minimal attempts to be backward compatibile. We
won't try to be incompatible, but if a better way is discovered to do
something, then it might be put in even if it will "break" existing code.
-----
cheers,
Derek Parnell
5. Re: NO!!!!
- Posted by mswayze at TRUSWOOD.COM
Feb 09, 2001
I hesitate to get involved in this thread as I come from a VBesque
background.
I have looked at every example of an EU-IDE I can find (alpha,beta or
otherwise(GB-EU-IDE included), what I was hoping to find was an extensible
component structure whether it were cut and past (classes?) or drag and
drop(controls?) and like Chris I get bogged down in all the extra 'stuff'
that goes along with it. The IDE supplied with the 050 version of Win32lib
being the most functonal (at least as far as a window with widgets) and also
the most obtuse when it comes to figuring out where it gets things from. I
had looked at a developing JavaIDE that was being done entirely in Java (1.3
I believe, with both AWT and Swing classes) and from a starting point
standpoint the non coded 'future' menu items etc. were already showing.
Java is pretty well defined possibly because of the $$ behind it even open
source as it is, ditto for any of the M$ stuff.
What I would like to see is more of the documentation for 'where' the
components(classes/controls?) figure in to IDE usage as well as a 'standard'
methodology for those as individual 'includes'. ie include only those
'components' necessary (even though it were to add some redundant code).
programming for me is a 'hobby' and I like it as painless as possible, but
if I wanted to add a property (picture,etc.) to a 'control' it sure would
be nice to be able to be able to know where to 'add' it. A seperate
'include' for a particular control would make this a lot easier.as well as a
'standard' format etc. for that 'component'.
Swayze
mswayze at truswood.com
kswayze at bellsouth.net
----- Original Message -----
From: "Chris Bensler" <bensler at mailops.com>
To: <EUforum at topica.com>
Sent: Friday, February 09, 2001 9:30 AM
Subject: RE: NO!!!!
> How about seperating it into seperate libs? To keep the libs specific to
> Win32Lb.. give them the extension *.w32
> Just symantics, but well worth the trouble if you are able to reduce the
> size of the main lib..
> Who says I WANT to use listboxes, edit controls.. groups, or even
> buttons for that matter..
> Take windows for example..
> There is the imminent KERNEL.DLL, then there are the extras.. CTRL.DLL,
> CTRL3D.DLL, etc.. etc..
>
> I think the size of the main lib can be diminished to a tenth of it's
> current size if you are able to restructure it. maybe use OOP
> The kernel should include the main event handlers.. and OOP processor,
> if you choose to develop your own..
> It shouldn't include any classes.. They should be seperate libs.. Just
> like WINDOWS..
> I hate to say they did something right, but they didn't make billions
> for nothing..
>
> Keep in mind, this is just my thoughts, I'm definitely no expert, and I
> DO see that it would be VERY difficult.. but in the long run, it would
> be easier, as well as more convenient for everyone, if you could do it
> that way..
> For win32lib coders as well as users..
> The library would be much easier to expand, and probably we would see a
> lot more user contributed additions, if this were possible..
> Instead of fumbling through.. what is it now 285?.. of code in one
> module.. break it up!! (and that's the compacted version!!)
>
> If I could simply write the class module with the events, properties,
> and handlers that I would need for my class alone, I would at least try
> to do so..
> As it is now.. it's certainly not possible for me to even attempt to
> change anything.. I have tried, and gave up after having to work my way
> through the maze of code that is there..
> Users should never have to look at the kernel..
> Just the individual class libs.. From these they could see what things
> they are able to do ,and what they aren't..
>
> To accomplish this, win32lib would definitely need a lot of
> restructuring.. possibly even re-writing the whole thing.. but to me
> this should be priority #1..
> Do you wish to continue to implement everything that people see as a
> neccessity, or to tell them that they can't have it? Would be much
> easier to tell them to code it themselves..
>
> I wish I could help, but I'm far from proficient in Win coding, not to
> mention even very familiar with win32lib coding, let alone win32lib
> SOURCE coding..
>
>
> Chris
>
> Derek Parnell wrote:
> > Hi Everyone,
> >
> > I'd be more than happy to take ideas and submissions for Euphoria Coding
> > Standards. I'm trying to put one together right now for use with
> > Win32lib
> > but the ESL could use it too.
> >
> > ----- Original Message -----
> > From: "sephiroth _" <euman2376 at yahoo.com>
> >
> > > What have you DONE to Win32lib?!?!?! Look at that code! It looks like
> > > someone shrouded...no, scrambled the code and tried to put it back
> > > together!
> >
> > Thank you - I tried very hard to make it obscure.
> >
> > Not really. I wrote a utility (eucompress.exw) that takes any euphoria
> > file
> > and tries to reduce its size by stripping comments and unrequired
> > whitespace. If I can be bothered, I'll go the next step and remove
> > unrequired linefeeds too. I was going to rename identifiers to smaller
> > ones
> > but debugging would then be just too hard.
> >
> > The real code is in win32lib_full.ew. This contains better whitespace
> > usage
> > and comments and the library documentation.
> >
> > > In my entire life, I have not SEEN such bad style!
> >
> > Still new to programming then are you?
> >
> > > This library is incompatible with earlier versions.
> >
> > So? No one promised compatibility, in fact, until v1.0 we are warning
> > people
> > that there are going to be minimal attempts to be backward compatibile.
> > We
> > won't try to be incompatible, but if a better way is discovered to do
> > something, then it might be put in even if it will "break" existing
> > code.
> >
> > -----
> > cheers,
> > Derek Parnell
> >
>
6. Re: NO!!!!
- Posted by dcuny at LANSET.COM
Feb 09, 2001
Chris Bensler wrote:
> How about seperating [Win32Lib] into
> seperate libs?
I've been urging Derek to wait until Robert adds namespaces to Euphoria
before restructuring the code. But it's not clear when that will happen.
> Who says I WANT to use listboxes, edit
> controls.. groups, or even buttons for
> that matter...
Structuring the library so that it's better organized seems to me an
excellent goal. Stucturing it so that you could leave out sections of the
library seems laudable. Structuring it so you can leave out individual
elements of the library - considering how interconnected they are - seems
like overkill.
Compartmentalizing each control to stand alone would result in an even
larger library, since large chunks of code would be duplicated between
controls. Trying to eliminate this with inheritance would inflict OOP onto
the library, carrying it's own overhead and additional complexity.
> I think the size of the main lib can
> be diminished to a tenth of it's
> current size if you are able to
> restructure it. maybe use OOP
Adding an extra level of OOP to the library - especially considering that
Euphoria doesn't support OOP - seems unnecessary to me. There are other ways
to accomplish the same goal.
> It shouldn't include any classes..
> They should be seperate libs.. Just
> like WINDOWS..
I'm not sure what Windows you are referring to, but it's not the Win32 API
that I've come to know. The Win32 API is only loosely 'class' structured.
> I hate to say they did something right,
> but they didn't make billions for nothing..
Maybe you are thinking of the MFC? Most people who work with GUI APIs pretty
much agree that the Win32 API is a mess, compared to just about anything
else.
> If I could simply write the class module
> with the events, properties, and handlers
> that I would need for my class alone, I
> would at least try to do so..
Take a look at Llama for an attempt to create a 'clean' set of OOP wrappers
around the Win32 API. Since Euphoria doesn't support OOP, the implementation
isn't all that simple, after all. Much of the code is a struggle to make the
Win32 model fit the OOP model, and it's not a good fit.
> To accomplish this, win32lib would definitely
> need a lot of restructuring.. possibly even
> re-writing the whole thing.. but to me this
> should be priority #1..
I don't see the library as being *that* terribly broken. It's certainly
large, but considering the scope of the library, I don't think that's a
valid complaint.
Even if Win32Lib were terribly broken, I think the prudent thing to do would
be to hold off and see how Robert plans on implementing namespaces.
-- David Cuny
7. Re: NO!!!!
- Posted by tone.skoda at SIOL.NET
Feb 09, 2001
Win32Lib isn't designed to be fast when it will become very big.
For example: Everything you create in Win32Lib goes thru
create() function. What if some day there would be
1000 different things that could be created?
Then that create() function would become slower, let's not
even talk about WndProc where every message is processed -
1000 ifs would make it slower.
The way Win32Lib is designed, there isn't much
to break to smaller files, because everything is connected
within a few big functions.
8. Re: NO!!!!
On 9 Feb 2001, at 13:34, tone.skoda at SIOL.NET wrote:
> Win32Lib isn't designed to be fast when it will become very big.
> For example: Everything you create in Win32Lib goes thru
> create() function. What if some day there would be
> 1000 different things that could be created?
> Then that create() function would become slower, let's not
> even talk about WndProc where every message is processed -
> 1000 ifs would make it slower.
That where the execution of vars, and not needing to predeclare things, would be
most
handy.
************************
global function create(sequence createwhat)
goto createwhat
if error return("no such function","errorcode") end if
:win_main
-- do winmain stuff here
return(whatever)
:menu
-- do main menu here
return(whatever)
:messagebox
-- make a message box here
return("yeas, it's done","this is where")
end function
*************************
The interpreter or compiler could optimise so the targets are pre-munged, and
it's an
machine code compare to get to the targets, very fast. But then, Robert is
against
executing variables, goto's, and premunging.
Kat
9. Re: NO!!!!
Wellll.... you can do this *sort* of thing already in Euphoria.
----------------
global constant Kerror_BadFunc = -1,
Kerror_BadParms = -2
global constant Kwin_main = 1,
Kmessagebox = 2,
Kmenu = 3
sequence doit doit = {}
global procedure setdoit(integer idx, integer rid)
-- Use this to establish a creation routine.
-- 'idx' is the code for the type of thing being created.
-- 'rid' is the routine_id that will do the creation.
if idx > length(doit) then
doit &= repeat(-1, idx - length(doit))
end if
doit[idx] = rid
end procedure
-- Create a main window.
function win_main(sequence parms)
-- do winmain stuff here
return(whatever)
end function
-- Create a menu
function menu(sequence parms)
-- do main menu here
return(whatever)
end function
-- Create a message box
function messagebox(sequence parms)
-- make a message box here
return("yeas, it's done","this is where")
end function
-- Launch the requested creation function.
global function create(integer createwhat, sequence parms)
integer rc
rc = Kerror_BadFuncId
if (createwhat <= length(doit))
and (createwhat > 0)
and doit[createwhat] >= 0
then
rc = call_func(doit[createwhat], {parms} )
end if
return rc
end function
-- Set up some internal creation functions.
setdoit(Kwin_main, routine_id("win_main") )
setdoit(Kmenu, routine_id("menu") )
setdoit(Kmessagebox, routine_id("messagebox") )
------------------
Using a scheme like this means that you can define your own private creation
routine and then just set the "doit" value and calling create(), just like
the built-in controls. You can even override the built-in creation routines
this way.
------
Derek Parnell
Melbourne, Australia
(Vote [1] The Cheshire Cat for Internet Mascot)
----- Original Message -----
From: "Kat" <gertie at PELL.NET>
To: "EUforum" <EUforum at topica.com>
Sent: Saturday, February 10, 2001 9:38 AM
Subject: Re: NO!!!!
> On 9 Feb 2001, at 13:34, tone.skoda at SIOL.NET wrote:
>
> > Win32Lib isn't designed to be fast when it will become very big.
> > For example: Everything you create in Win32Lib goes thru
> > create() function. What if some day there would be
> > 1000 different things that could be created?
> > Then that create() function would become slower, let's not
> > even talk about WndProc where every message is processed -
> > 1000 ifs would make it slower.
>
> That where the execution of vars, and not needing to predeclare things,
would be most
> handy.
>
> ************************
> global function create(sequence createwhat)
> goto createwhat
> if error return("no such function","errorcode") end if
>
> :win_main
> -- do winmain stuff here
> return(whatever)
>
> :menu
> -- do main menu here
> return(whatever)
>
> :messagebox
> -- make a message box here
> return("yeas, it's done","this is where")
>
> end function
> *************************
>
> The interpreter or compiler could optimise so the targets are pre-munged,
and it's an
> machine code compare to get to the targets, very fast. But then, Robert is
against
> executing variables, goto's, and premunging.
>
> Kat
>
>
>
>
>
