www.digitalmars.com         C & C++   DMDScript  

D - SWT port - first step

reply Brad Anderson <brad sankaty.dot.com> writes:
I'm starting a new thread so we can discuss the best way to do a 
proof-of-concept for a D port of SWT.  For reference, we were under "Active 
Projects" and "D gui" before this)

I would like to propose that we accomplish the following:

1.  Write enough code so that the following works

/+
  +	HelloWorldGUI.d
  +/

import dwt.widgets.Display;
import dwt.widgets.Shell;

int main (char[][] args) {

	Display display = new Display();
	Shell shell = new Shell(display);
	shell.open();
	while ( !shell.isDisposed() ) {
		if ( !display.readAndDispatch() ) {
			display.sleep();
		}
	}
	display.dispose();
}


2.  Demonstrate that it works on Win32 and Linux/GTK.

3.  Figure out a forum for the small team to exchange ideas and communicate 
(rather than loading up the DMD newsgroup.)  We will report back on feasibility.

This should give us enough of a look at the plumbing of SWT.  We can see where 
we will have to work hard to get around a feature in Java that D does not have, 
or that we want to improve because we have more capabilities in D.

For the moment, let's assume we're going to use listeners and try to stay as 
close to SWT as possible.  Optimizations can come much later...

What can we leave out for the proof-of-concept?  Unicode, threading,

Thoughts?  Volunteers?  Platform preferences?

I don't have dev access to a Linux box, so I'll probably hack around with
Win32. 
  I can, however, set up a forum using phpBB on a public site.

Brad
Jan 20 2004
next sibling parent reply John Reimer <jjreimer telus.net> writes:
I'll respond in more detail to this in a bit, but for now here are a
couple of links to the SWT toolkit so others can get familar with it:

Download and web viewable cvs:

http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/main.html

The Developer's SWT page:

http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/dev.html


Also, it probably be wise to get further information on the license of
this toolkit.  I know we would be modifying it in D, but I don't know what
our obligation would be for adopting the design. 

Notice also, in the above website, there are branches for win32 and Gtk in
place.  This is a good thing :).

Oh and watch out, the name "dwt" might not be so popular ;-).

Nice sample! 

Later,

John
Jan 20 2004
next sibling parent John Reimer <jjreimer telus.net> writes:
On Tue, 20 Jan 2004 21:48:38 -0800, John Reimer wrote:

 The Developer's SWT page:
 
 http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/dev.html
 

The CVS tree is actually in the above link, not the first one provided.
 Also, it probably be wise to get further information on the license of
 this toolkit.  I know we would be modifying it in D, but I don't know what
 our obligation would be for adopting the design.
 

From what I can see, the code is under the Mozilla Public License 1.1. I'm not familiar with the extent of it. I guess I'll be doing some reading.
Jan 20 2004
prev sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
In the code, links to Common Public License 1.0

http://www.eclipse.org/legal/cpl-v10.html

However, we'll be putting this into the public domain.  IANAL, but I would
guess 
that we could give some lip-service to Eclipse, SWT, and IBM in documentation 
(not source code), and then choose our own license.

BA

John Reimer wrote:

 I'll respond in more detail to this in a bit, but for now here are a
 couple of links to the SWT toolkit so others can get familar with it:
 
 Download and web viewable cvs:
 
 http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/main.html
 
 The Developer's SWT page:
 
 http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/dev.html
 
 
 Also, it probably be wise to get further information on the license of
 this toolkit.  I know we would be modifying it in D, but I don't know what
 our obligation would be for adopting the design. 
 
 Notice also, in the above website, there are branches for win32 and Gtk in
 place.  This is a good thing :).
 
 Oh and watch out, the name "dwt" might not be so popular ;-).
 
 Nice sample! 
 
 Later,
 
 John

Jan 20 2004
next sibling parent John Reimer <jjreimer telus.net> writes:
On Tue, 20 Jan 2004 23:54:46 -0600, Brad Anderson wrote:

 In the code, links to Common Public License 1.0
 
 http://www.eclipse.org/legal/cpl-v10.html
 

You're right. For some strange reason I landed in a directory with a source file using the "Mozilla Public License." Must have been just a few files.
 However, we'll be putting this into the public domain.  IANAL, but

 would guess that we could give some lip-service to Eclipse, SWT, and IBM
 in documentation (not source code), and then choose our own license.
 

Ok, I don't know much about this. As long as we know what we're doing. I was browsing some of the Java code, and it's great! I think for the most part, it will be pretty easy to convert. The os dependent features are clearly indicated with calls like OS.GetClassInfo(...) for win32. It'll be a snap to duplicate in place. Gtk would be similar. This just means we have to work on class structure and members. Most of it is pretty similar to what D can do. This looks promising! Later, John
Jan 20 2004
prev sibling next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
IANAL??

"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bul4fv$2cg1$1 digitaldaemon.com...
 In the code, links to Common Public License 1.0

 http://www.eclipse.org/legal/cpl-v10.html

 However, we'll be putting this into the public domain.  IANAL, but I would

 that we could give some lip-service to Eclipse, SWT, and IBM in

 (not source code), and then choose our own license.

 BA

 John Reimer wrote:

 I'll respond in more detail to this in a bit, but for now here are a
 couple of links to the SWT toolkit so others can get familar with it:

 Download and web viewable cvs:


 The Developer's SWT page:


 Also, it probably be wise to get further information on the license of
 this toolkit.  I know we would be modifying it in D, but I don't know


 our obligation would be for adopting the design.

 Notice also, in the above website, there are branches for win32 and Gtk


 place.  This is a good thing :).

 Oh and watch out, the name "dwt" might not be so popular ;-).

 Nice sample!

 Later,

 John


Jan 20 2004
next sibling parent "davepermen" <davepermen hotmail.com> writes:
hehe, no comment:D

"Matthew" <matthew.hat stlsoft.dot.org> schrieb im Newsbeitrag
news:bul76l$2gku$1 digitaldaemon.com...
 IANAL??

Jan 20 2004
prev sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
I am not a lawyer


Matthew wrote:
 IANAL??
 
 "Brad Anderson" <brad sankaty.dot.com> wrote in message
 news:bul4fv$2cg1$1 digitaldaemon.com...
 
In the code, links to Common Public License 1.0

http://www.eclipse.org/legal/cpl-v10.html

However, we'll be putting this into the public domain.  IANAL, but I would

guess
that we could give some lip-service to Eclipse, SWT, and IBM in

documentation
(not source code), and then choose our own license.

BA

John Reimer wrote:


I'll respond in more detail to this in a bit, but for now here are a
couple of links to the SWT toolkit so others can get familar with it:

Download and web viewable cvs:


http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/main.html
The Developer's SWT page:


http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/dev.html
Also, it probably be wise to get further information on the license of
this toolkit.  I know we would be modifying it in D, but I don't know


what
our obligation would be for adopting the design.

Notice also, in the above website, there are branches for win32 and Gtk


in
place.  This is a good thing :).

Oh and watch out, the name "dwt" might not be so popular ;-).

Nice sample!

Later,

John



Jan 20 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
Ah ...

Well, better than a couple of the alternatives I'd postulated ... :)

"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bul83n$2hlk$1 digitaldaemon.com...
 I am not a lawyer


 Matthew wrote:
 IANAL??

 "Brad Anderson" <brad sankaty.dot.com> wrote in message
 news:bul4fv$2cg1$1 digitaldaemon.com...

In the code, links to Common Public License 1.0

http://www.eclipse.org/legal/cpl-v10.html

However, we'll be putting this into the public domain.  IANAL, but I



 guess

that we could give some lip-service to Eclipse, SWT, and IBM in

documentation
(not source code), and then choose our own license.

BA

John Reimer wrote:


I'll respond in more detail to this in a bit, but for now here are a
couple of links to the SWT toolkit so others can get familar with it:

Download and web viewable cvs:




The Developer's SWT page:




Also, it probably be wise to get further information on the license of
this toolkit.  I know we would be modifying it in D, but I don't know


what
our obligation would be for adopting the design.

Notice also, in the above website, there are branches for win32 and Gtk


in
place.  This is a good thing :).

Oh and watch out, the name "dwt" might not be so popular ;-).

Nice sample!

Later,

John




Jan 21 2004
prev sibling next sibling parent reply Mark T <Mark_member pathlink.com> writes:
In article <bul4fv$2cg1$1 digitaldaemon.com>, Brad Anderson says...
In the code, links to Common Public License 1.0

http://www.eclipse.org/legal/cpl-v10.html

However, we'll be putting this into the public domain.  IANAL, but I would
guess 
that we could give some lip-service to Eclipse, SWT, and IBM in documentation 
(not source code), and then choose our own license.

Why not just use the Common Public License? It is very open and acceptable to SourceForge which would be a good place to put this project once it gets rolling.
Jan 21 2004
parent Brad Anderson <brad sankaty.dot.com> writes:
No arguments here.


Mark T wrote:

 In article <bul4fv$2cg1$1 digitaldaemon.com>, Brad Anderson says...
 
In the code, links to Common Public License 1.0

http://www.eclipse.org/legal/cpl-v10.html

However, we'll be putting this into the public domain.  IANAL, but I would
guess 
that we could give some lip-service to Eclipse, SWT, and IBM in documentation 
(not source code), and then choose our own license.

Why not just use the Common Public License? It is very open and acceptable to SourceForge which would be a good place to put this project once it gets rolling.

Jan 21 2004
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bul4fv$2cg1$1 digitaldaemon.com...
 In the code, links to Common Public License 1.0

 http://www.eclipse.org/legal/cpl-v10.html

 However, we'll be putting this into the public domain.  IANAL, but I would

 that we could give some lip-service to Eclipse, SWT, and IBM in

 (not source code), and then choose our own license.

The license does not allow it to be placed into the public domain. However, the license does appear to be compatible with our purposes, and I don't see any problems with it.
Jan 22 2004
prev sibling next sibling parent reply "davepermen" <davepermen hotmail.com> writes:
I think thats a nice idea. I hope to have a forum since quite some while
anyways, hehe.

But i think there should be one change done right from the start: use
delegates, not listeners. This is NOT an optimisation, but such a general
design issue, i think it should be done right from the start. For all other
points, i fully agree.


"Brad Anderson" <brad sankaty.dot.com> schrieb im Newsbeitrag
news:bul1v1$281v$1 digitaldaemon.com...
 I'm starting a new thread so we can discuss the best way to do a
 proof-of-concept for a D port of SWT.  For reference, we were under

 Projects" and "D gui" before this)

 I would like to propose that we accomplish the following:

 1.  Write enough code so that the following works

 /+
   + HelloWorldGUI.d
   +/

 import dwt.widgets.Display;
 import dwt.widgets.Shell;

 int main (char[][] args) {

 Display display = new Display();
 Shell shell = new Shell(display);
 shell.open();
 while ( !shell.isDisposed() ) {
 if ( !display.readAndDispatch() ) {
 display.sleep();
 }
 }
 display.dispose();
 }


 2.  Demonstrate that it works on Win32 and Linux/GTK.

 3.  Figure out a forum for the small team to exchange ideas and

 (rather than loading up the DMD newsgroup.)  We will report back on

 This should give us enough of a look at the plumbing of SWT.  We can see

 we will have to work hard to get around a feature in Java that D does not

 or that we want to improve because we have more capabilities in D.

 For the moment, let's assume we're going to use listeners and try to stay

 close to SWT as possible.  Optimizations can come much later...

 What can we leave out for the proof-of-concept?  Unicode, threading,

 Thoughts?  Volunteers?  Platform preferences?

 I don't have dev access to a Linux box, so I'll probably hack around with

   I can, however, set up a forum using phpBB on a public site.

 Brad

Jan 20 2004
parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <bul743$2ggn$1 digitaldaemon.com>, davepermen says...
But i think there should be one change done right from the start: use
delegates, not listeners. This is NOT an optimisation, but such a general
design issue, i think it should be done right from the start.

Would it be possible to explain in a few lines of D how you would implement the listener functionality with delegates?
Jan 21 2004
next sibling parent "davepermen" <davepermen hotmail.com> writes:
well.. something like this:

Window win = new Window("Title");
win.onClose = delegate void() {
    app.postQuitMessage();
}

not sure about the syntax again, i always mix delegate void() and void
delegate() :D

now, for the implementation, it would look like this:

class Window {
    /*....*/
    void delegate() onClose;
}

and in the event handler (win32 here)

case WM_CLOSE:
     if(curWin.onClose !== null) curWin.onClose();
     break;



something in that idea..

"Georg Wrede" <Georg_member pathlink.com> schrieb im Newsbeitrag
news:bulgt3$30s1$1 digitaldaemon.com...
 In article <bul743$2ggn$1 digitaldaemon.com>, davepermen says...
But i think there should be one change done right from the start: use
delegates, not listeners. This is NOT an optimisation, but such a general
design issue, i think it should be done right from the start.

Would it be possible to explain in a few lines of D how you would implement the listener functionality with delegates?

Jan 21 2004
prev sibling next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bulgt3$30s1$1 digitaldaemon.com>, Georg Wrede says...
In article <bul743$2ggn$1 digitaldaemon.com>, davepermen says...
But i think there should be one change done right from the start: use
delegates, not listeners. This is NOT an optimisation, but such a general
design issue, i think it should be done right from the start.

Would it be possible to explain in a few lines of D how you would implement the listener functionality with delegates?

Try to look at Andy's dfbth. I just browse it but looks quite simple and to the point. I'm going to change DUI to a very similar scheme. We should decide on listener(no) versus delegates(yes) from the begining. Ant
Jan 21 2004
parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <buls8d$gdi$1 digitaldaemon.com>, Ant says...
We should decide on listener(no) versus delegates(yes)
from the begining.

Ok, so have I missed the main tradeoffs?
Jan 21 2004
next sibling parent "davepermen" <davepermen hotmail.com> writes:
delegates are actually simply the language feature that replace listeners.
see c#.

there is no use in anything else. it's much less typing effort, espencially
for the one defining the interface.

btw, Ant, i know dbfkgdfklösdf. i like it. i just hate the name:D

"Georg Wrede" <Georg_member pathlink.com> schrieb im Newsbeitrag
news:bum2da$pp7$1 digitaldaemon.com...
 In article <buls8d$gdi$1 digitaldaemon.com>, Ant says...
We should decide on listener(no) versus delegates(yes)
from the begining.

Ok, so have I missed the main tradeoffs?

Jan 21 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
Georg Wrede wrote:

 In article <buls8d$gdi$1 digitaldaemon.com>, Ant says...
 
We should decide on listener(no) versus delegates(yes)

from the begining.

Ok, so have I missed the main tradeoffs?

I'm not certain of any really notable advantages of using listener interfaces over delegates; SWT uses the former because Java simply does not offer any other way to accomplish the observer pattern. Listeners are very poorly suited to D primarily one reason: D does not support Java's notion of inner classes. This means that, to write a handler for any button, one must manually write a class that implements ButtonClickedListener (or whatever), accepts and stores a reference to its parent class, (if it needs it, which is very frequently the case) and responds to the event. A delegate can just be stuffed inside a collection without regard for the inheritance heirarchy. (sure sounds sloppy when you phrase it like that) D also supports function literals, which makes it very easy to attach a trivial little handler to a button. button.onClick ~= delegate(ClickEvent event) { printf("Hello!\n"); }; button.onClick ~= &this.exitApp; -- andy
Jan 21 2004
next sibling parent Georg Wrede <Georg_member pathlink.com> writes:
In article <bum409$sbp$1 digitaldaemon.com>, Andy Friesen says...
A delegate can just be stuffed inside a collection without regard for 
the inheritance heirarchy. (sure sounds sloppy when you phrase it like 

:-)
that)  D also supports function literals, which makes it very easy to 
attach a trivial little handler to a button.

button.onClick ~= delegate(ClickEvent event) { printf("Hello!\n"); };
button.onClick ~= &this.exitApp;

Thanks, Dave, Ant, and Andy! This is really cool!
Jan 21 2004
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Andy Friesen" <andy ikagames.com> wrote in message
news:bum409$sbp$1 digitaldaemon.com...
 Listeners are very poorly suited to D primarily one reason: D does not
 support Java's notion of inner classes.  This means that, to write a
 handler for any button, one must manually write a class that implements
 ButtonClickedListener (or whatever), accepts and stores a reference to
 its parent class, (if it needs it, which is very frequently the case)
 and responds to the event.

 A delegate can just be stuffed inside a collection without regard for
 the inheritance heirarchy. (sure sounds sloppy when you phrase it like
 that)  D also supports function literals, which makes it very easy to
 attach a trivial little handler to a button.

 button.onClick ~= delegate(ClickEvent event) { printf("Hello!\n"); };
 button.onClick ~= &this.exitApp;

That's why D doesn't do inner classes - delegates are a much nicer solution for the same problem.
Jan 22 2004
parent Ant <duitoolkit yahoo.ca> writes:
On Thu, 22 Jan 2004 10:08:13 -0800, Walter wrote:

 
 "Andy Friesen" <andy ikagames.com> wrote in message
 news:bum409$sbp$1 digitaldaemon.com...
 Listeners are very poorly suited to D primarily one reason: D does not
 support Java's notion of inner classes.  This means that, to write a
 handler for any button, one must manually write a class that implements
 ButtonClickedListener (or whatever), accepts and stores a reference to
 its parent class, (if it needs it, which is very frequently the case)
 and responds to the event.

 A delegate can just be stuffed inside a collection without regard for
 the inheritance heirarchy. (sure sounds sloppy when you phrase it like
 that)  D also supports function literals, which makes it very easy to
 attach a trivial little handler to a button.

 button.onClick ~= delegate(ClickEvent event) { printf("Hello!\n"); };
 button.onClick ~= &this.exitApp;

That's why D doesn't do inner classes - delegates are a much nicer solution for the same problem.

What! that's not a valid reason. Inner classes solve other problems. How difficult are they to implement? (In my ignorance) you just a need a pointer to the outer class it's very simple to do... please add them before 1.0 for instance they are useful to build GUIs. leds file browser contains a nested class to hold the file tree - it would benefit from the nested class being inner, nothing to do with events. leds project browser (some thing)... leds addToProject functions (not released yet) contain nested classes create the user interfaces - they would benefit if we have inner classes. In all these 3 examples I have to pass extra parameters to the nested classes ctors to have access to the outer class members. Ant
Feb 03 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Andy Friesen wrote:
 Listeners are very poorly suited to D primarily one reason: D does not 
 support Java's notion of inner classes.

That leads me to an idea: if we would write an automatic Java->D converter, running over an inner class could automatically convert it into a delegates, no? -eye
Jan 23 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
Georg Wrede wrote:
 In article <bul743$2ggn$1 digitaldaemon.com>, davepermen says...
 
But i think there should be one change done right from the start: use
delegates, not listeners. This is NOT an optimisation, but such a general
design issue, i think it should be done right from the start.

Would it be possible to explain in a few lines of D how you would implement the listener functionality with delegates?

I've written a nifty little template class that wraps a collection of delegates into a single callable entity. <http://ikagames.com/andy/d/Listener.d> Right now it's a struct. (because I didn't want to bother new'ing it) It would have to become a class, and implement the proper SWT listener interface. (maybe as another template argument) Then it just becomes a matter of adding an instance of the listener to some place in the existing SWT class, and attaching it to SWT's existing listener infrastructure via the usual addXXXXXXListener method. There are other ways to do it, naturally, but I think this might be best, as it requires almost no alteration of the underlying SWT semantics. Less thinking is good. :) -- andy
Jan 21 2004
next sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
 From this and the above examples, I'm sold on delegates instead of rote
copying 
of listeners already in SWT.  This falls into the category of taking advantage 
of a feature in D that isn't in Java.  Hopefully a bunch of you will be 
available to assist.

Andy Friesen wrote:

 Georg Wrede wrote:
 
 In article <bul743$2ggn$1 digitaldaemon.com>, davepermen says...

 But i think there should be one change done right from the start: use
 delegates, not listeners. This is NOT an optimisation, but such a 
 general
 design issue, i think it should be done right from the start.

Would it be possible to explain in a few lines of D how you would implement the listener functionality with delegates?

I've written a nifty little template class that wraps a collection of delegates into a single callable entity. <http://ikagames.com/andy/d/Listener.d> Right now it's a struct. (because I didn't want to bother new'ing it) It would have to become a class, and implement the proper SWT listener interface. (maybe as another template argument) Then it just becomes a matter of adding an instance of the listener to some place in the existing SWT class, and attaching it to SWT's existing listener infrastructure via the usual addXXXXXXListener method. There are other ways to do it, naturally, but I think this might be best, as it requires almost no alteration of the underlying SWT semantics. Less thinking is good. :) -- andy

Jan 21 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <bumbl7$17ft$3 digitaldaemon.com>, Brad Anderson says...
 From this and the above examples, I'm sold on delegates instead of rote
copying 
of listeners already in SWT.  This falls into the category of taking advantage 
of a feature in D that isn't in Java.  Hopefully a bunch of you will be 
available to assist.

The thing I don't like on the SWT project is that the way to make to linux is through GTK. Been there, done that... :( well, maybe the SWT has some excelente ideas on how to do it... might be interesting to learn how SWT APIs are converted to GTK calls... Ant
Jan 21 2004
parent John Reimer <jjreimer telus.net> writes:
 The thing I don't like on the SWT project is that the way to make to linux
 is through GTK.
 Been there, done that...
 
 :(
 
 well, maybe the SWT has some excelente ideas on how to do it... might be
 interesting to learn how SWT APIs are converted to GTK calls...
 
 Ant

It shouldn't be as hard or as bad, since the SWT has the internal.gtk type calls already mapped out. At least we know what will be used. We can use that section of the java source to map out a D gtk module with extern(C) calls (similar to how you did it in DUI). From there we just need to make calls similar to the java OS.foo calls. Of course, it's easy to talk about it. :) As a first project, I guess I could try making a gtk module based on the JNI. I can use DUI as a guidline :). The harder part may be the whole modification process of changing from listeners to delegates. I don't know how that will go. Later, John
Jan 21 2004
prev sibling parent reply John Reimer <jjreimer telus.net> writes:
 I've written a nifty little template class that wraps a collection of
 delegates into a single callable entity.
 <http://ikagames.com/andy/d/Listener.d>

Thanks for this. I've studied it and it looks quite promising. As you say, it is quite nifty :-). That's an interesting use of associative arrays you've got in there. Just have to change the "instance" keyword to the "!" symbol, I think.
 Right now it's a struct. (because I didn't want to bother new'ing it) It
 would have to become a class, and implement the proper SWT listener
 interface. (maybe as another template argument)

We should be able to do that.
 Then it just becomes a matter of adding an instance of the listener to
 some place in the existing SWT class, and attaching it to SWT's existing
 listener infrastructure via the usual addXXXXXXListener method.

OK
 There are other ways to do it, naturally, but I think this might be
 best, as it requires almost no alteration of the underlying SWT
 semantics.  Less thinking is good. :)
 
   -- andy

It's a great start. Thanks! John
Jan 21 2004
parent Andy Friesen <andy ikagames.com> writes:
John Reimer wrote:
 Thanks for this. I've studied it and it looks quite promising. As you
 say, it is quite nifty :-).  That's an interesting use of associative
 arrays you've got in there. Just have to change the "instance" keyword to
 the "!" symbol, I think.

Whoops. I've updated it with the newest version. (I use that template in a bunch of places. It's only a matter of time before they start to fall out of sync) -- andy
Jan 21 2004
prev sibling next sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bul1v1$281v$1 digitaldaemon.com...
| ...
|   I can, however, set up a forum using phpBB on a public site.
|
| Brad
|

If you wish, you can send me a line and I'll a category for it in
http://s3.invisionfree.com/ln5yrestgv/index.php.
And if anyone is interested, I haven't made any progress in Delphi4D due to
(guess, guess) lack of time. I hope I can get back to it soon.
Although I remember Walter saying he didn't like the need to distribute an
application with a dll. Delphi4D apps will work like that. Should I keep it
on? Mmm, time for a poll. You know where to vote ;).

-----------------------
Carlos Santander Bernal
Jan 21 2004
prev sibling parent reply Mark T <Mark_member pathlink.com> writes:
any update?
Feb 01 2004
parent Brad Anderson <brad sankaty.dot.com> writes:
I'm afraid real work is rearing its ugly head and time is scarce.  We've 
made some progress, and I'll have more time next week, but it's slow 
going.  We'll post when we have something.

Cheers,
Brad


Mark T wrote:
 any update?
 
 

Feb 01 2004