Stan's Blog

New R1.0 feature - textboxes...

2005-11-25T04:31:00.000-08:00

Hardly revolutionary I'm sure you'll agree, however dotWidget has been without them until now. Using the new api widgets can create an unlimited number of text boxes, configuring them all independantly of each other. The widget is notified through the Notify() hook (Name = "_textbox_invoke") when the user hits the Enter key.

For the moment only single line edit controls are supported, however full multi-line rich-text support is planned for the future. On the right you can see the first widget to take advantage of this new feature - a simple Google search...

Why Release 1.0 now?

2005-11-24T12:49:00.000-08:00

Simple really, if I didn't do it now, it'd probably never get it done. Also, I found myself thinking about other applications - those that seem to be in perpetual 0.x status (Litestep) and those that seem to fly through major version numbers (iTunes, Internet Explorer) like a dose of salts.

I got round to thinking what 0.x releases mean to people (and what they should mean to people) and I kind of figured that a 0.x release means either 'Alpha' or 'Preview', with Beta releases normally preceding a 1.x release. This means that things such as 'Release 0.8 Beta 1' are pretty much nonsensical as it implies a Beta of an Alpha!

As for dotWidget, it's more-or-less this time last year that R0.6 came out (and two years ago that I actually started work on it in the first place) so, although R1.0 won't hit any anniversaries, it's nice that it was at least announced now.

April round-up...

2005-05-04T00:25:00.000-07:00

Making good progress, so here's a quick round-up of what's in and working so far:

Desktops

These aren't sevice-based as they don't fit the model well, instead there's a series of global functions that allow you to manage them. Note I say 'them' rather than 'it' - that's right, DarkFiber will feature the ability to have multiple desktops, each of which can have its own background (transparent, solid colour, or image) and - of course - shells can interact with them to develop virtual window (and host) managers. A subset of the api is as follows:

set_desktop_count(number_of_desktops)
activate_desktop(desktop)
show_desktop()
hide_desktop()
set_desktop(element, data)

In addition to these functions, there will also be the ability for clients to subscribe (hence why I was initially looking to make this a service) to receive notifications when the number of desktops of changed, a particular desktop is activated, etc.

General shell tasks

Progress on the real having-to-do-what-explorer-does is also going well. The famed built-in DDE server that Explorer uses is now started and stopped, and the necessary windows and undocumented function calls are now created and called so that the tasks.service can use the HSHELL_* notification messages rather than a snooping timer to update its list (it also means that those annoying flashing task button messages are captured at last) - much of the code for this was borrowed from the ROS Explorer project, of which I'm deeply indebted to.

Lastly...

I haven't forgotten about the more detailed service architecture post I promised; I'll get this done soon, along with an introduction to the next piece of the puzzle - ColdFusion...

Progress report (picture)

2005-04-23T02:53:00.000-07:00

Screenshot showing progress to date

DarkFiber Services Architecture

2005-04-21T20:04:00.000-07:00

I wasn't going to bother with a standardised architecture for the DarkFiber services - with them being built-in to the core library anyway it seemed a bit like overkill - but, after working on the api's for the timer.service and the hotkey.service a generic architecture started to develop anyway.

With timers and hotkeys, you add and remove them, then you receive notifications of when something happens (the timer elapses; the hotkey gets pressed) - so we already have a standard interface here:

AService.Add(something)
AService.Remove(something)

Of course, now we're building a list of things we've added to a service, we can also do searching and enumerating, so we get:

AService.Find(something)
AService.RewindItems
AService.GetItem(something)

Of course, for this to be completely generic, the something has to conform to a standard as well. Initially, I was going to go down the fully object-oriented route by having the something be something that implements the most basic melon interface there is - MObject - and leave it at that. Instead though, I've taken a slightly more old-fashioned/c-based approach and have created a COM datatype called MSERVICEREQUEST that takes the place of the something. A nice side of this is that the interface is kept very small and is future-proofed. Here's how it works:

Instead of having Add(), Remove(), Find(), etc. methods in the interface, these have all been consolidated into a single method - DoRequest() - which looks like this:

MService_DoRequest(Request As MSERVICEREQUEST) As M_RESULT

Request defines the request itself along with any relevant data required to complete the request. For example, if the request is an add then most likely you'll need to provide a name for the object to be added, the virtual keycode and modifier(s) (if it's a hotkey) or the interval (if it's a timer). All this is contained in MSERVICEREQUEST, which looks like this:

typedef struct MSERVICEREQUEST {
M_SERVICE_COMMANDS Command;
MMessageSink *ReplyPort;
MMessage *Reply;
BSTR Name;
BSTR StrData;
LONG Id;
LONG LngData;
} MSERVICEREQUEST;

With the exception of the Command value, all other values are optional - they're only relevant to the command itself. The nice thing about this is that the DoRequest() method can be used to enable two-way communication between a service and a client - for example, if the command was a ficticious 'get_info' one, the client could pass this and the name of the object it wanted information about; the service would then populate the other fields accordingly.

Now we've discussed the basics, one or two examples are probably appropriate. At the time of writing, there are three service currently in existence, all probably around 90% complete. These are the hotkey.service, timer.service and task.service (I've written them using their display names so feel free to read them as 'hotkey service' and not 'hotkey dot service').

The timer.service is the most simple - all it does is allow clients to add timers; it then sends a message back to the client every time the timer interval elapses. To add a timer you need to send an add request and provide a name and an interval for the timer - null (empty) names and timers of less than 1 are not allowed. The pseudo code for this is as follows:

With myrequest
.Command = M_SERVICE_ADD
.Name = "my_timer"
.LngData = 500
End With

If the_timer_service.DoRequest(myrequest) = M_OK Then
{ request completed okay }
Else
{ something failed }
EndIf

Now, this wouldn't work. Why? Well, there are two more fields we must also specify when adding a timer - Reply and ReplyPort - which detail a melon message and messagesink respectively. These are required as otherwise the service would have no way of contacting the client when the interval times out. Here's the corrected request structure:

With myrequest
.Command = M_SERVICE_ADD
.Name = "my_timer"
.LngData = 500
.Reply = new_Message(100)
.ReplyPort = Me
End With

This would now succeed and every 100ms or so the adding class would receive a message with the What field set to 100.

That's it for this update, next time I'll talk about subscribing to a service and how services are accessed from clients.

DarkFiber Introduction

2005-04-18T15:42:00.000-07:00

As already mentioned in the news post on the k23productions site, DarkFiber is a toolkit aimed at making development of Windows Shell replacements a lot easier by taking care of all the background interaction between Windows and the end-user graphical interface. Here I'll give a brief outline of the planned features:

Desktop management, along with support for multiple virtual desktops
Start Menu content management, including support for 'merging' the common and user applications together into a single menu
Boot-up application launching - both registry and Start Menu applications - as well as the ability to boot applications from a script
System Tray item management
Running task management
Timer and hotkey management
Other Windows version-specific features
Filesystem monitoring
VBScript wrapper objects, including safe error and procedure handling

If all this sounds like a sales brochure then, sorry, I've been on a consulting course recently and I'm finding it hard to shake off. I'll be posting more information about all of these elements over time, in each I'll discuss the proposed API and explain reasons behind some of the decisions I've made. I've also uploaded the initial version of the library to CVS here for those of you interested in following development.

Update

2005-04-06T15:18:00.000-07:00

Not posted here in quite a while... Which is frustrating as this blog is rapidly ending up the same as all my other on-line diaries: unused.

Firstly, to manage expectations, don't expect anything ground breaking in this one - suffice to say that since the last post (Sep '04) I've gotten married so the wife and I are busy decorating, demolishing, and re-decorating the new house. To make matters worse, I'm working away from home a lot these days so I don't get much time to see the wife; let alone time to do much coding. Oh, and spring has sprung in the UK now (at least, it has today) so that means more time in the garden and less on the computer (good and bad I'm sure you'll agree).

The other concern I have is that I'm not really sure what to work on - I made a promise to myself (and several others) that I'd make some serious progress on eggShell but, to date, I'm no way near as forward with it as I'd like to be and I'm concious that the next release of dotWidget should be out on the shelves...

Anyway I wouldn't like to end this post on a negative note, so here's the mustard on what's going on in the workshop at the moment.

Menu Bar - the top bar from the various eggShell screenshots. This has now been pulled out from eggShell (as was dotWidget) and is it's own standalone application - although there's some nice inter-process communication still in there...

Terminal - the terminal application from eggShell. Again, now a standalone application.

And something going by the name of DarkFiber - but I'll tell you about that soon...

Welcome to my Blog...

2004-09-24T09:18:00.000-07:00

Well, surely everyone starts with one of these sort of messages don't they?