Re: NO!!!!

new topic     » goto parent     » topic index » view thread      » older message » newer message

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? blink
> >
> > > 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
> >
>

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu