You may or may not know that the Delphi IDE uses the ActionBands VCL components for its main menu and as a result does not support Accessibility (not good, I know). I’m happy to report that with our next release of Delphi this problem has been resolved. We’ve added MSAA support to the ActionBand components and therefore the IDE’s menus will support accessibility. Unfortunately, we’re unable to retrofit the technology to work with previous releases although it was considered.
I’ve been lobbying to get Borland to send me to Microsoft‘s PDC this year but it’s not looking too good so I
thought I’d take a shot at winning a free trip from
Microsoft so I’ll apologize in advance to those of you who read my blog
I think I deserve the trip because I’m in a fairly unique
position working on a Windows development tool that lots of people use which
allows them to leverage Microsoft technology. How many people can say that? The
more I know about MS technology the better I can help our team develop and
implement creative ways to make Microsoft technology more accessible to our
It would be a unique opportunity to see first hand from
Microsoft itself as to why this new technology is important and give MS a chance
to get me jazzed about it (which I’m sure they’ll do based on my previous PDC
’01 experience) and in turn incorportate development support for it in Delphi.
As an example, I now work on ASP.NET support in Delphi and C#Builder.
Keeping up with the latest technologies Microsoft’s implementing in Windows
is incredibly important when you work on a Windows development tool and PDC is
simply a great place to step away from the keyboard, learn about new technology
and think about ways to make leveraging that technology easier for our customers
which is what Delphi is all about.
It would also give me a chance to hang out with any ex-Borland Microsoft
employees which is always fun.
So, here’s how I’d share my PDC trip:
- As arguably Borland’s most active blogger I’ll blog about it, of course!
- I’ll go over the session schedule in advance and find out what sessions
developers here think would be most useful and plan my attendance based on how I
can help as much of our team as possible. (btw, in 2001 I skipped only 1 session
timeslot the entire week and yes by the end of the week I was exhuasted from
walking the conference hall)
- Upon returning from the conference I’ll prepare and present an All Hands
talk with the team to discuss what I’d learned, answer questions and let people
know how and where they can find out more.
- I’d work to ensure Delphi continues it’s tradition of allow our customers to
leverage Windows technology faster and easier than ever before.
- Lastly, I’d get some sleep and recover from information overload.
So, if you happen to work for Microsoft and your
reading this post for the contest please, help me help you and send me to PDC so
I can work on cool new features that will help Borland’s customers utilize all
your cool new technology.
Whew, I’m glad I don’t have do to this every day!
I’ve been experimenting with Accessiblity
in VCL and was wondering just what sort of impact the lack of a fully Accessible
VCL has been? So, if you’ve either lost work because the VCL isn’t fully Section
508 compliant or have been unable to use Delphi for a client as a result I’d
love to hear from you? Likewise, if you’ve been writing software for the
government or other public institution and Accessiblity hasn’t been an issue I’d
also be interested.
One problem I see with QC is that, at least in some
cases, we’ve given people the impression that QC is a black hole into which bugs
simply disappear. This can happen when a customer submits a bug that is left in
the system and never reviewed for months on end. This is bad.
Ok, it’s bad, now what are we doing to fix it. Well, I’ve talked to John
Kaster about getting an RSS feed from
QC which lists only new bugs. The current feed for Delphi lists any bug that’s been
changed in QC and therefore typically contains 100’s of bugs making it difficult
to wade through. We’ve been working on the Welcome page to allow it to support
custom RSS modules. Once we get the new bug feed we’ll be able to add a section
to the Welcome page (which we use heavily internally for communication) and get
these new bugs in front of QA and R&D every day. We could also use a feed
for bugs that appear to have been abandoned so that we can improve the
“freshness” of QC and make customers more happy and therefore (hopefully) more
inclined to log bugs.
Hey John, how’s that new feed coming? 🙂
If you have other suggestions as to how we can improve QC please let me know.
I’m seeing a bunch of comments where people simply prefer the Delphi 7 layout over the new embedded
designer layout and it makes me wonder if our next release should use the D7
layout by default. Personally, I now like the embedded designer layout more than
D7 but admittedly it took me awhile. Every time we’ve changed the appearance of
the IDE we’ve succeeded in raising the ire of a number of people most of whom,
after a fashion, typically agree that the new changes eventually grow on them to
the point where they like them better than the old. But, our latest changes were
by far the most dramatic and it seems perhaps we may want to reconsider what the
default layout for our next release is going to be.
Thanks to some previous comments like this
we know we’ve got some work to do to improve the floating layout so that it
works more like D7.
So, let me know, what would you like to see the default layout of the IDE be,
like D7 or like D2005?
[Updated July 13, 2005]
Wow, thanks for all the feedback, based on this entirely unscientific “survey”
it looks like our decision to move to the single window IDE style was the right
move. Oh, and no, I won’t/can’t comment on any dates for upcoming releases.
I was just reading this
blog comment where Marc talks about “tons” of bugs being logged against Delphi to some “internal
board”. My first thought was why? Why would someone not give their bug report
even a fighting chance of being fixed? In fact, it has no chance of being fixed
short of someone else running into the same problem and logging it to Borland‘s QualityCentral (QC) website.
Now, logging bugs to a forum like that is fine if you want to make sure that
the readers of said forum are aware of the bug so they can avoid wasting time
if/when they run into it, but if you actually want to give the bug any sort of
chance of being fixed then you’d better make sure it gets logged to QC
IMO, posting a bug to some private or public
forum/newsgroup/blog/wiki/website/whatever even if it’s a Borland public
newsgroup is pretty much like sending it to the bit bucket so I’d suggest saving
your time and effort. Please, post bugs to QualityCentral. Write a bug
that gives us the best chance of reproducing the problem without having you
there to help and give a good description and if necessary indicate why it’s
something we should fix so that we can prioritize it accordingly.
I’ve read enough blog comments (replying to my posts) but more or less avoided answering this question. Well, I think it’s time I commented on this and hopefully, provide a peek into what we’re doing. First, I’ll start by saying that I’m not going to talk about updates to Delphi 2005, it’s not my place and not something I can/will comment on. What I want to mention are some of the things that we’re doing right now during our current development cycle related to quality.
A comment: While Borland doesn’t have an official presence on the Borland public newsgroups we (R&D/QA) do have people who read them on a regular basis. We also read the various product reviews posted to the web (some of which I’ve pointed out here) and we try to follow closely what people are saying about the product. Internally, we get feedback from our Sales Engineers in the various regions around the world which provides a bit different view that newsgroups alone and we also get feedback from Developer Support and our Dev Rel guys (DavidI, Anders and John) from their visits to developers around the world.
If you’ve been reading my blog then you’ve probably already seen this, this, this and this where I’ve been discussing some of the inner workings of our development process and answering some great blog comment questions. In my last post I talked about Handling Bugs but I didn’t cover some of the additional things we’re doing. In our current cycle, we’ve assigned a Quality Architect who is a long time Delphi R&D engineer and whose responsibility is to focus strictly on quality issues throughout the product. In fact, this person wasn’t assigned feature work so as to focusing solely on quality. Some of the functions of this new role:
- Keeping a “report card” on the quality of the product at each milestone and reviewing it with R&D/QA/Docs.
- Investigating, isolating and fixing or helping the engineer responsible in the area fix high priority quality issues throughout the product.
- Attending Bug Councils (see here) and keeping close track on the overall quality picture.
- He’s created a Quality Team which meets weekly to discuss issues
While not a comprehensive list of responsibilities these are some of the core functions of this new role.
What else are we doing?
We’re combing through QualityCentral to ensure that we are aware of and addressing issues coming from the field. For example, Chris Hesik has blogged about several instances where he’s used automated QC reports to locate and fix various issues in Delphi 2005.
We’ve allotted a much longer bug fix/stabilization period prior to RTM as well as kept tight control of feature “creep” and cut features originally slated for the release that would likely make meeting our quality goals difficult. We’ve implemented a more formal Design Specification and Review process where we’re leveraging wiki technology to allow literally anyone on the team to review, comment and help improve design documents for many the development initiatives involved in this release.
Our management team initiated bug councils at the very beginning of the process (this is generally not the case) working to prioritize the “bug base” and ensure that the worst issues are prioritized correctly and addressed accordingly.
R&D has spent time working to isolate, reproduce and fix some long standing, very difficult to reproduce issues improving our own productivity as well as the quality of the product. In fact, I’ve recently worked on a bug that was resolved via remote desktop from Japan (now that IMO is remote).
We’re leveraging various efforts of the Delphi community itself to help uncover issues and improve performance through initiatives such as the Fastcode project.
Lastly, as you can see from Allen’s recent post, we’ve really got people thinking about quality.
These are but a few of the real and ongoing efforts inside the Delphi group these days to improve overall quality. So, I hope that helps answer the question I posed above.