1. RE: New win32lib and XML
> -----Original Message-----
> From: Mike Sabal [mailto:Sabal.Mike at notations.com]
> Subject: Re: New win32lib and XML
>
>
>
> How would these changes affect programs written with older versions of
> win32lib that have several hundred lines of
> contant control = create(....)?
>
> Mike Sabal
All the existing methods will still be valid. This new idea is one of a
couple of new ways to define controls.
--
Derek
2. RE: New win32lib and XML
> -----Original Message-----
> From: Euman [mailto:euman at bellsouth.net]
> Subject: Re: New win32lib and XML
>
>
>
> Derek please have a look at SMEL....(written in euphoria)
> http://users.pandora.be/tommycarlier/eu
I already have. I was discussing SMEL with Tommy before he released it. In
the end, although he did adopt a couple of my suggestions, I decided not to
go with it because it was still too verbose, and didn't support nested
attributes. SMEL is a good alternative to XML but it is overkill for my
needs. I want to make Win32lib EASIER to use, not harder.
> RANT: I dont understand why no one (but me and a few) use .res files.
> Parsing .res files 16 or 32bit is easy and allows you to use many
> of the advanced IDE's out there...If an extension to .res file parsing
> was made to allow for things like color, bitmaps, control
> size if certain
> UI is used etc it would make more since to me.
Maybe you're right, but the extensions wouldn't be compatible with .res
anymore, and so if we are going that way, why not use a syntax that is more
suited to the task at hand.
My example didn't show that a LOT of reasonable defaults are used, and it
also supports relative positioning of controls.
> Otherwise, SMEL should be the alternatative to using XML.
Agreed, but I'm not advocating XML either.
--
Derek
3. RE: New win32lib and XML
> -----Original Message-----
> From: Pete Lomax [mailto:petelomax at blueyonder.co.uk]
> Subject: Re: New win32lib and XML
>
>
>
> On Tue, 6 Jan 2004 09:02:14 +1100, Derek Parnell
> <ddparnell at bigpond.com> wrote:
>
> >I'm already ahead of you. In the next win32lib, it would be
> possible to define a window and its controls in a text file.
> This can then be used at run time to instantiate the actual
> Windows controls. Its syntax is a bit but more compact than
> XML. Your example above would look something like ...
> >
> > window, caption={Dialog Example} at={0,0} size={320,200}
> >
> flags={new,ws_popup,ws_clipsiblings,ws_caption,ws_sysmenu,ws_e
> x_dlgmodalframe}
> > font={Comic Sans MS,10}
> >
> > label,caption={Static Text Example}, at{32,29}, size={70,11}
> >
> > editbox, name=1000, at={32,76}, size={78,14}
> >
> > icon, at={32,96}, size={32,32}, picture=xyzzy.ico
> >
> > button, caption={&OK}, at={86,179}, size={50,14}
> >
> > button, caption={&Cancel}, at={183,179}, size={50,14}
> >
The example above doesn't show it all. There are lots more features.
> Nice. How about applying a font or other attribute to more than one
> control?
default, font={Comic Sans MS,10)
Now the default font is this. This can be used to supply different defaults
for most attributes. Exceptions include the 'name' and 'caption' attributes.
> Where's the design? 
What's one of those?
> >Let's say you create these lines in a file called
> 'MyDialog.form', then your app would read ...
> >
> >--------
> > createForm( "file=MyDialog.form" )
> >
> > global procedure Activate_Dialog_Example(integer self,
> integer event, sequence parms)
> > . . .
> > end procedure
> >
> > global procedure Click_OK(integer self, integer event,
> sequence parms)
> hmm.
> What if I have several xxxDialog.form files, and several button,
> caption={&OK} ...? Or do you mean that in the absence of a name
> attribute, and/or provided the caption is unique, and/or Click_OK is
> expected to use getParent or similar to figure stuff out?
Each form file specifies a single window and its controls. Your app can call
createForm(...) as many times as it likes to create different windows/dialog
forms. Each control, including the form itself, must have a name and the
name is unique within the application. You can either explictly give a
control a name, or if not provided, win32lib will use the caption text to
form a name. If you don't provide a name= or caption= attribute, win32lib
makes up a name (but this is not very useful). There is a new function,
getNameId(<control name>) that returns the control ID value.
The name is used to format standard routine names for event handlers. A new
routine called StartApp() can be used in your app to supply a call-back
routine_id, that is called when win32lib needs to get a routine_id from your
program. This is a very brief overview as there are lots of options here.
The goal is to allow the coder to get maximum usability with minimum effort
from win32lib. For example, one of the attributes is the 'events=' one. This
allows you to specify which events your control will respond to. However,
most controls have default events already defined so this attribute is only
rarely needed. The minimum a coder needs to do is define global routines
with standard names, and include the "w32start.ew" file at the end of the
source code file.
I must state that all this is in ADDITION to existing ways of defining
controls. And you can mix and match methods as needed. For example, you can
call createForm and still add extra controls to it using create().
> >Am I getting close?
> Very.
I have converted many demos to the new form and found it quite liberating.
The code looks cleaner and changing form layouts are much less troublesome.
Especially when using the relative positioning options.
--
Derek
4. RE: New win32lib and XML
Derek Parnell wrote:
> I already have. I was discussing SMEL with Tommy before he released it.
> In
> the end, although he did adopt a couple of my suggestions, I decided not
> to
> go with it because it was still too verbose, and didn't support nested
> attributes. SMEL is a good alternative to XML but it is overkill for my
> needs. I want to make Win32lib EASIER to use, not harder.
Still too verbose? Might be true indeed, but you can create a lot of
powerful constructions, and you don't have to write the name of every
element/attribute: standard, frequently used names can be omitted. Every
control has an ID, so the ID-attribute is standard, so you can omit it.
Instead of:
form(id=!Form1 size=[300,200])
{
button(id=!Button1 size=[50%,20px] location=[10,10]
OnClick=!Button1_Click);
label(id=!Label1 size=[200,20] location=[10,40]){ "This is a label with a
variable ", var(id=!Label1Var);, " in it." }
}
You can say:
form(!Form1 size=[300,200])
{
button(!Button1 size=[50%,20px] location=[10,10] OnClick=!Button1_Click);
label(!Label1 size=[200,20] location=[10,40]){ "This is a label with a
variable ", var(!Label1Var);, " in it."}
}
Doesn't support nested attributes? True, but attributes are supposed to be
simple properties and not children. And if you want to have an attribute
that contains more than 1 value, you can use a sequence-value (which can
be nested): look at the example above: size and location are attributes
with sequence-values.
--
Tommy Carlier
tommy online: http://users.pandora.be/tommycarlier
