I previously mentioned the idea of a "living readme" here
have since been in a blog comment dialog wondering if it would be helpful for us
to talk about, blog or otherwise recognize bugs in the product even if we didn't
have a fix. Well, Chris Hesik
has gone one step further and essentially done just that with a post
about a debugger bug
2005. I can't wait to see
the response to Chris' post. I'd love to know what you think of this, let me
I was talking to Allen today and asking if he thought it might actually be useful if we were to make some sort of public acknowledgement of perhaps a few of the most talked about bugs from the newsgroups even in the case where we may not be able to ship a patch or update to correct the problem because of scheduling/testing/business conditions/development costs/integration issues etc. The idea being that at least people would know that we're "dialed in" and aware of an issue that affects a good number of our users (I'm not talking about "small" stuff here). Basically, I'm talking about a "living readme.txt" if you will.
What do you think, would this help even if a patch/fix weren't forthcoming?
Disclaimer: This idea is something I've had for quite some time but only now decided to post. It should in no way be misconstrued as having anything to do with any outstanding issues related to any existing Borland
products. Basically, I'm thinking something more along the lines of the Cluetrain Manifesto
where at least we could have some communication about the problems that are impacting people.
I understand that the point of a rant really isn't to provide useful
information but instead to vent some anger to a group of people who, hopefully,
can share your pain in some meaningful way. However, if ever you are inclined to
post a rant if you could keep the following in mind it might help your fellow
trenchmates who take the time to read your rantings to actually help you out.
- Focus only on the facts as you know them
- Be as specific as possible about what the problem is and how you got there
- If there is an error message involved post the complete text of the
- Try not to embellish or if you have to try to be conservative
- Avoid name calling
- At the end, state that you feel better, I know it'll be hard to do, but that
way people will know you're ready to move on and actually be open to offers for
If you can't seem to do any of the above you might want to save yourself the
typing and utilize whatever your favorite release mechanism is not related to a
That's all I can think of for now, if I come up with anything else I'll add
on as necessary.
I know this issue has been pretty well discussed but someone recently asked me about it again and I put together a small example to help illustrate the problems that arise when using the MSHTML control and trying to preserve source code.
Here is what we hand the MSHTML control
we get this back (without editing anything btw):
Now, to point out the differences...
- All tags are now uppercase
- runat="server" on title tag is gone
- Missing the first closing (notice the last one is preserved)
- A single space was added between "two" and
- The wrapped text has been unwrapped
- The order of the table tag attributes has been reversed
- The quotes around the table tag attribues have been removed
- The case of the table tag attributes has been changed
- TBODY tag has been added
- A closing TR tag has been added (but no closing TD??)
- All whitespace has been removed (except of course where it was added see above)
So, as you can see when it comes to source preservation using the MSHTML control we definately have our work cut out for us thus we currently reformat the markup to make it readable again. I'll have more on this later.
Recently, this bug report was brought to my attention. Unfortunately, I'd fixed this bug a long time ago but the fix never made it into Delphi 2005 VCL/VCL.NET.
I've posted a fix for this problem here. I'll be sure to get this checked in. :)
In light of the recent developments surrounding the end of
Mainstream support for Visual Basic I've decided to add this entry to my
blog so I can list resources for developers looking to convert from VB to Delphi. I'll keep this entry
"open" so that as I find things or as people point them out to me I'll add them
here. To kick things off I'll name a few of the features in the IDE that were
designed to make it easier for any Visual Basic/Visual Studio developer to start
- Probably the most important would be the VB
keybinding which you can set from the Editor Options page of the
- Next, is the Visual Studio syntax highlighting colors (also available from
the Tools|Options dialog)
- Delphi 7 and later also have Object Inspector (Properties window) color
settings that match Visual Studio which you can select from the Tools|Options
- Delphi also has a set of "VB-like" functions available in the StrUtils.pas
file including things like LeftStr, RightStr, MidStr and several others.
Here are a few more resources:
Ok, that gets us started. If you have more suggestions
please leave a comment and I'll add things to this entry as necessary.
Updated March 28, 2006:
Removed the link to Delphi
wiki's VB page as it is now blank. Added "Why Delphi??" link.
I'd like to try to found out what people dis/like about the Welcome page
included with Delphi 2005.
We spent quite of bit of time redesigning it for this release and I'm curious to
know if people find it useful. Feel free to post comments either way but if you
dislike the page please include at least a few examples of what you don't like.
For those of you just looking for a way to turn it off altogether we got that,
how about telling us what would be useful enough for you to keep it around??
Btw, has anyone logged that request in QualityCentral?
Be sure to take a look at these posts as well: