Random whining on just about anything
I don’t know if this is a Delphi thing or an XP thing, but regardless, it’s pretty stupid. If you try to bring up the Help and the Help window is already open, the system is smart enough to blink the icon on the taskbar to let you know that it’s already open, but apparently not smart enough to bring the damn window forward. L-A-M-E.
(this link will take you to a QuickTime movie)
Look at how easy it is to tell the difference between the various overloaded methods.
Absurd, isn’t it? Here is an excerpt from the DocuShare 6 API reference, which is in standard JavaDoc format, and demonstrates a much better way of displaying summary information for overloaded methods (in this case, constructors):
Hey I think it’s wonderful that Delphi 2009′s help system contains an entire reference section for VB Script, something WHICH I HAVE NO USE FOR NOR WILL EVER HAVE ANY USE FOR. Plus I love waiting around for display the help window – gives me extra time to contemplate the lake across the street.
Sorry – but if you’re a RemObjects dev, time to put down the crack pipe.
Session.Values['RemObjectsDeveloper'] := ‘CrackSmoker’;
That’s the line of code I had to add to get the stupid piece of shit server to keep a session around. Without it, the session goes away. 2 days I wasted on this crap – nothing in the docs about it at all.
Short video to show how excruciating this is:
This one is courtesy of Delphi 2009 (which appears to allow undoing past save! WOO HOO!).
It’s amazing how bad this shit is. I mean look at this crap – all I was trying to do was to copy a file from a local drive to a network drive, using Windows Explorer, and I get this:
I eventually realized it was asking me – in general – if I wanted to move or copy files, not to select move or copy. So it should have asked “Do you want to enable moving or copying of files from this zone”, or something similar.
Millions of dollars in usability testing and this is what we’re left with. Sad.
The “zone” thing, too, is confusing. I honestly have no idea what the hell they mean by zone in this context.
I should come up with a commercial to counter the “I’m not cool enough” anti-Apple ad: “Guess I’m not dorky enough to understand this crap”.
Today was the day when I feel that I “got” RemObjects. Below is an email that I sent to a colleague (Ed) which turned out to be correct:
Since migrating to a tree control, I no longer have the need for a ClientDataSet. Instead, I am populating the tree control directly as I iterate the XML returned from DocuShare.
Joe has just emailed me a sketch of the UI he is looking for, which involves separating out the collections from the documents. The collections will be the only items in the tree view, with a grid being used to display each collection’s documents. So now it looks like I’ll be using a ClientDataSet again just for the document list.
I spent 5 min going through the RemObjects SDK web site just now, and I think a light bulb just went off in my head (and I apologize here in advance if you guys have described this already and I didn’t get it on the 1st pass). Please tell me if I have anything wrong….
First, a quick recap: I’ve been building the DocuShare layer as a component with methods like “UploadDocument”, “ListCollection”, etc. The client of that component is currently my form in my proof of concept app. This means that the ugliness of the returned XML is partially exposed to the client (in the form of an interface used to iterate that XML).
Enter RemObjects. Even before I start using RemObjects, I believe I should create a higher-level component that encapsulates the DocuShare component, and hide all the ugliness there. The methods of this component will eventually become public interface to the RemObjects service. This service could then define the format of the data returned to the client, completely hiding any details of how I communicate with DocuShare. I could also potentially expose the RemObjects service as a true SOAP-based Web Service, and therefore achieve most of the advantages we thought we’d get by building a Java-based web service to talk to DocuShare instead of using it’s XML/HTTP interface. The problem I mentioned this morning will still exist, though, but I’ve got that covered.
Does this sound right?
—————————————-
Ed’s response (hope he doesn’t mind):
Your light-bulb moment is accurate. What you’re describing is a DAL (DocuShare Abstraction Layer) and is spot on. This is exactly how we treat our DAL (Database Abstraction Layer) and it simplifies things greatly on the client. Let the server do the heavy lifting and keep the client nice and lightweight.
—————————————-
to which I replied:
Benz is gettin’ excited!
