| |
Index
|
| |
Home
Projects
Writing
About Me
|
| |
| |
|
| |
Blog Categories
|
| |
All Posts
Borland
ECO
Personal
Photos
Projects
Misc.
|
| |
| |
|
| |
Recent Blog Entries
|
| |
|
| |
| |
|
| |
Previous Posts
|
| |
| March 2006 |
| Sun |
Mon |
Tue |
Wed |
Thu |
Fri |
Sat |
| |
|
|
1 |
2 |
3 |
4 |
| 5 |
6 |
7 |
8 |
9 |
10 |
11 |
| 12 |
13 |
14 |
15 |
16 |
17 |
18 |
| 19 |
20 |
21 |
22 |
23 |
24 |
25 |
| 26 |
27 |
28 |
29 |
30 |
31 |
|
| Jan Apr |
|
| |
| |
|
| |
The views expressed on this
site are my own, and do not reflect the views of my employer,
Borland Software Corporation mgroves @ borland.com |
|
|
|
|
Wednesday, 18 January 2006
|
|
I'll be showing off some of the new features of ECO III at tonight's ADUG (Australian Delphi User Group) Sydney meeting.
It's essentially a repeat of my Borcon US session. Borland will be providing the pizza and drinks, so come along if you can.
|
|
Tuesday, 15 November 2005
|
|
Last week in the middle of all the stuff going on at Borcon in San Francisco, David and I snuck out late one night to a video conference room at Kinko's to present 2 hours of Delphi 2006 to 400 developers in Seoul, Korea.

It was 2 hours of nail-biting suspense, as I was expecting the video or the audio to let us down at some point, but except for a few minutes of noise partway through, it all went very smoothly. We were up on a 200 inch screen, which is kinda scary, as I was feeling quite tired from jet-lag and usual late nights at Borcon, so the bags under my eyes must have been about a foot tall

Not sure why it still surprises me when technology works as it is meant to. Maybe this stuff may yet deliver on its promise of letting me travel less.
|
|
Monday, 26 September 2005
|
|
I spoke with Matthew Overington, a journalist in Australia, a little while back about Model Driven Development in general, and ECO in particular. The resulting article showed up on BuilderAU back in August.
I wouldn't normally post links to sites that have linked to an
article I'm in, but I'm so tickled by this one, I just had to post. The
article has been referenced on the Healthy Hair website, specifically
on the Hair Loss blog (Who knew there was a blog about hair loss? Why wasn't I told?).
Now the less kind amongst you who know what I look like, will no
doubt be able to construct some terribly amusing reason why I'd be on
this site. Oh, how we'd laugh! Sorry to spoil it for you, but you'd be
wrong. There were no photos in the article. Ha!
My mum will be so proud. I'm not even upset that they messed up the quote. This one's going straight into the pool room.
|
|
Monday, 29 August 2005
|
|
I've been in New Zealand this week doing some Borland Developer Day's events. Mornings we've been focusing on ECO, afternoons we've been focusing on the new MDA features in the next version of Together.
Anyway, during the ECO session in Wellington, I was talking about the AutoForms capabilities, and how you could register your own AutoForms for specific types. This is a really useful feature, as you can use the default AutoForm during early parts of your development, so that you can focus on getting the model developed, and then when ready, you can create custom forms to be used to view and edit your objects. Registering them with the AutoForm service means that you don't have to change any of the code in your app that display's your AutoForm, it will automatically use the new form you have registered.

After the session, one of the guys in the audience who'd been using ECO for awhile came up to me asked how to do this. To be honest, I thought I'd already blogged about this. Apparently not, so I had a few hours to kill in the Qantas lounge in Christchurch while I waited for my flight home, so I thought I'd write something up. You can grab the sample code here.
A few things first. If you haven't seen the default AutoForm capabilities, download the source for this project and open it in Delphi 2005 Architect. Bring up Winform1, and note that I've set the ECOAutoForm property on the grdAllPeople DataGrid to True. Now I can simply double-click on a row in my grid, and an autoform will be created. This is probably the simplest way to get ECO to display an AutoForm for an object.

NB: If you can't see an ECOAutoForm property in the DataGrid's on your form, you probably need to add an ECOAutoFormExtender component to the form. This will insert some ECO-specific properties into the DataGrid.
Also click on Button3, which is the button labeled "Show Autoform" next to the upper grid. I've also set it to display an AutoForm for the currently selected Person in the grid. I've enabled this by setting it's ECOListAction property to ShowAutoForm, and setting its BindingContext to my grdAllPeople grid, and its RootHandle property to the ExpressionHandle holding the collection of Person objects, in this case, ehAllPeople. This is probably the second simplest way to display an AutoForm for an object.

If you want to display an autoform for an ECO object via some other method (e.g., via a context menu, etc), then the following code (Which is also in the Click event of Button4 in the sample project) will achieve the desired result:
procedure TWinForm1.Button4_Click(sender: System.Object; e: System.EventArgs); var autoContainer: IAutoContainer; begin if Assigned(cmhSelectedAppointment.Element) then begin autoContainer := AutoContainerService.Instance.CreateContainer( cmhSelectedAppointment.Element, AutoContainerArgs.Create(EcoSpace, False, AutoContainerMemberVisibility.AllMembers, ContainerReusage.NeverReuse)); if Assigned(autoContainer) then Form(autoContainer).Show; end; end;
Firstly, we're checking that an Appointment object has been selected in our grid, by seeing if the Element attribute of our CurrencyManagerHandle is assigned. Then, we're using the AutoContainerService's CreateContainer method to get back a reference to an IAutoContainer for the selected Appointment. Lastly, provided we got back a reference, we're casting it as a Form and calling show to display it.
Running the project should show that clicking the button to invoke this code has the same result as double clicking in the grid.
Personally any time I want to display a form in my ECO apps, I use this code. Yes, it's longer than just creating an instance of a custom form and assigning the ECOSpace and the ECO object you want to edit. However, bear with me for a minute and hopefully you'll see the advantage.
Open the fAppointmentAutoForm unit and have a look at the TAppointmentForm it contains. I designed this form like I would design any other ECO Winforms. File | New | Other...ECO Enabled Windows Form, drop my controls down. set the ReferenceHandle's ECOSpaceType and StaticValueTypeName properties, set up my databinding, etc. To convert this form into an ECO AutoForm, I have to do a few things:
1. Extend your form class so that it implements the IAutoContainer interface. You'll need to add the Borland.Eco.AutoContainers and the Borland.Eco.ObjectRepresentation namespaces to your interface uses clause. Use Ctrl-Space from within your class declaration to declare the BuildControls, HookUpGUI and set_ECOSpace methods, and extend the declaration of your EcoSpace property so that has a setter method (the aforementioned set_EcoSpace).
2. Ctrl-Shift-C from inside the form classes declaration to stub out the implementations of these new methods. The code within them looks like the following:
procedure TAppointmentForm.set_EcoSpace(value: EcoSpace); begin if value <> FEcoSpace then FEcoSpace := value; end;
procedure TAppointmentForm.HookUpGUI(ecoSpace: EcoSpace; element: IElement); begin FEcoSpace := ecoSpace; RHRoot.EcoSpace := self.EcoSpace; RHRoot.SetElement(element); end;
procedure TAppointmentForm.BuildControls(element: IElement; autoContainerArgs: AutoContainerArgs); begin // don't need to do anything, unless you intend writing a generic // autoform end;
Most of these should be fairly self explanatory. The BuildControls method is empty, however if you wanted to dynamically create controls on your AutoForm, this is where you'd do it.
3. So, now our AutoForm is complete, however we need to register it with the AutoFormService. To do ths, we define a simple Factory class. In the same unit, you'll see this under my form declaration. Its delcaration looks like this:
AppointmentAutoContainerFactory = class(System.Object, IAutoContainerFactory) public function get_AutoContainer: IAutoContainer; function Matches(modelElement: IModelElement): Boolean; end;
Its implementation looks like this:
function AppointmentAutoContainerFactory.get_AutoContainer: IAutoContainer; begin Result := TAppointmentForm.Create(nil); end;
function AppointmentAutoContainerFactory.Matches(modelElement: IModelElement): Boolean; begin Result := modelElement.Name.Equals(Appointment.ClassName); end;
You may need to add the Borland.Eco.UmlRt namespace to your Interface uses clause. The get_AutoContainer method is where we actually create an instance of our form. The Matches method will be called by the ECO Framework, passing in a reference to the model element for which it is trying to create an AutoForm. Your job in this method is to decide if your form will handle this class, in this case I'm checking whether it represents an Appointment, and if so returning true.
4. Lastly, I need to register my Factory with the AutoForm service, by adding the following code to the initialization section of the unit:
initialization AutoContainerService.Instance.AddFactory(AppointmentAutoContainerFactory.Create); finalization
That's it. Now when you run your app, you should notice that when you request an autoform for an Appointment object you'll get back our new form. This is regardless of how you request it (i.e.. double clicking in your grid, using the ECOListAction on your button, using the AutoForm code, ECOSpaceDebugger etc). You don't need to change any of your forms, you can make the change in one place and the rest of your app will follow. Way cool!
In the sample code, the initialization section code is commented out, so you can easily see the before and after effect.

|
|
Wednesday, 13 July 2005
|
|
So, we're getting close to the 24 hours of Delphi online radio thingy
(yes, I think that's the official name). The schedule is up here.
I'm going to be on at midnight PST, and then again at 11pm PST (which
thankfully is a much more civilised 5pm and 4pm respectively where I
am), but I'll be sticking my head in whenever I can. I'll also be
making an effort to be online for the ECO bits, which are:
- 3:00 am PST with Jan
- 3:45 am PST with Jonas
- 10:00 am PST with Daniel
- 7:00 pm pST with Randy
- 10:00pm with Tim and Dick
Hmm and Brian Long is always good value, and Marco, and..., OK, looks
like I'm not going to get much work done for the next 24 hours.
|
|
Wednesday, 20 April 2005
|
|
Jonas has just updated the ECO pmwiki with an interesting post on creating custom OCL operations, along with an example that implements a bunch of DateTime functionality that you can invoke from OCL. One of the guys mentioned this a few months back, and I've been waiting since then to get my hands on it. Hmmm, wonder if I have time to play tonight.....
|
|
|
SDA Asia magazine are holding their SDA.NET Conference 2005 in Singapore from the 24th to the 27th of May. This conference promises to be pretty cool for a bunch of reasons:
- There are a whole bunch of well known Delphi people speaking, including Michael Li, Neal Ford, Chad Hower and Hadi Hariri. Somehow I managed to sneak in there as well :-)
- As well, there are some great speakers from the MS side of the fence as well, such as Ingo Rammer, and the one that I'm most looking forward to hearing speak, Clemens Vasters.
- Half the sessions are totally free to attend. The other half require registration, but even that is ridiculously cheap (SGD$250 per day, including the pre-con and post-con tutorials).
So even if you're not based in Singapore, at that price, and with that lineup of speakers, how could you not attend? If you are going, let me know, maybe we can organise a meetup (Chee Wee and I know this great pub)
|
|
Thursday, 14 April 2005
|
|
Part of the reason I've been quiet on the blog lately (apart from work, travel, family life, ill dogs, and just general laziness) is that I've been working on a reasonably large ECO/ASP.NET application for use internally in Borland. Eventually I'd like to publish the source code (inspired as I am by Peter Morris) but trust me, you wouldn't want to see it in its current state.
Anyway, back to the point. Being a web app, part of it follows a fairly common web standard of organising content in a hierarchy of categories that users can use to navigate down into more specific areas. Think of the directory structure at Yahoo in the screenshot below

Anyway, this was relatively easy to implement in a model: a Category class that has an auto-association (ie. an association to itself) such that a Category can have 0..* child categories, and a Category can have 0..1 parent categories. It was also relatively easy to set up in ASP.NET so I could browse my way up and down these categories.

What had me stumped for awhile were the breadcrumbs. Breadcrumbs? Look in the Yahoo screenshot above. Near the top, it has a list of all the ancestor categories as links, so you can work your way back up to where you came from. I wanted to be able to get a list of the Category objects that make up the path from a specific Category all the way to the root. In the screenshot, it's Directory, Computers and Internet, Programming and Development, Languages, Delphi from least specific down to most specific. Once I had this in a handle, I could bind it to an ASP.NET Repeater component and Robert's your mother's brother. I didn't only need to access this path for the breadcrumbs, but that's a nice, visible example of what I needed.
I eventually came up with some fairly convoluted code that walked up the Parent association, adding each to a handle as I went (which involved some pretty funky casting along the way). That worked, but it left a fairly foul taste in my mouth. I thought ECO was supposed to stop me from having to write this sort of pointless plumbing code?
Well, obviously if there wasn't a better way I wouldn't be writing this article. After some help from Jesper and Jonas (thanks guys!) here's my current solution. I'm sure there are others, but I'm kinda fond of this one at the moment.

I've added a Derived Association, in fact another auto-association, called Path and made it uni-directional. When you reference this association you should get back all categories from the root down to the current Category. To make this happen, the Derivation OCL for the Path association looks like this:
if self.Parent.isNull then self->asSet else self.Parent.Path->including(self) endif
If the current Category is the root, its Parent will be null, and as a result we return a collection of just the current Category. However, if we are somewhere down the tree, then we use the including operator to add the current Category to its Parent's Path collection (ie. we're recursively calling this derived association).
Works like a bought one, as you can see in the screenshot below. The top left grid is showing all the Category objects, and also serves to let us select a particular category. The bottom left grid is showing the children of the currently selected Category, and the bottom right grid is showing the contents of the currently selected Category's Path association. Exactly what I needed.

Yes, the result is exactly the same as my convoluted code, and yes I had to learn a bit of OCL (this is the best OCL reference I've found so far, BTW. Thank you Anthony), but it just feels so much more ECO-like to be able to tell the framework what I want at a higher level, rather than having to explicitly say how to do it. Sure, I always want to have the option to take control over how things happen, but for stuff like this, I couldn't care less.
<Sigh> Once again I'm reminded, ECO is love.
Oh, you can download the source for this example here (and yes, I realise I can't spell, but then Delphi doesn't spell check my Project names for me, so it's not my fault).
|
|
Wednesday, 10 November 2004
|
|
Well, I didn't expect to be updating this quite so quickly, but it's my own laziness that caused it so I can't really complain.
I've updated my FileExplorer addin so that it behaves in a more civilised manner when it comes to where it places its packages than it used to.
I got the good oil from Allen on what I should be doing, spent a little time learning how to add Pascal scripting to my InnoSetup project (which is stupidly easy, BTW. InnoSetup rocks!), and the result is a setup that will hopefully play nicer with security issues, etc.
Of course, I said "should" and "hopefully" a few times above. I've tried to test it out as well as I can, but I'm sure you'll all let me know if there are any problems :-)
|
|
Tuesday, 9 November 2004
|
|
I've had a couple of people point out that the link to the sample source at the end of the Writing Solid Delphi Code article was dead. Well, I finally got around to fixing it, so all should be well now. Sorry guys.
|
|
Sunday, 7 November 2004
|
|
I've updated my FileExplorer addin for Delphi 2005, as well as adding a couple of new features, such as support for jumping direct to any of the paths in your VCL and .NET Library Paths. More info here
|
|
| |
|