Getting your fix: the DevExpress way

10 July 2008

We've recognized for a while that there's a minor flaw in how we disseminate fixes to our products. Sure, the primary method of doing so is to issue a new release, either minor or major, but sometimes it's necessary to post an intermediate fix in some fashion. At present this process is a little inefficient: you write to support asking for a fix, this message goes into the maw of our support system, lands on someone's desk and they then email you the required files.

Now, in actuality, not everyone wants intermediate fixes. They'll use a workaround until the next release is published and then start using the new version. However, sometimes there is no workaround and we jump into this somewhat inefficient process.

We thought about it a while and came to the conclusion that if we produce a code fix for an issue, we should make it available via the Support Center web UI for customers who need it urgently, as part of the page for that issue. We also decided that if no one actually wanted the fix that urgently, we should try and avoid doing the extra work in creating/updating the files (be they source files, DLLs, or assemblies) that a customer would need to download.

In other words, the code fix would be available by request only. The first customer that wanted the fix would trigger the extra work on our side to prepare a download package. Subsequent customers who wanted the same fix would just download the already prepared package. In essence, we should have a "load on demand" type system.

There are several types of fixes we produce

  • A small code fix for a certain file. This is of greatest benefit for our VCL customers since they are well used to modifying source code and recompiling. I would venture that our .NET customers wouldn't be that interested in this kind of fix. The extra work on our part here is not that great at all.
  • A complete set of source code files to replace the original files you've installed. Again this is of primary benefit to our VCL customers. .NET customers typically don't want to rebuild our assemblies (especially as we are not that likely to release our private signing key, sorry and all that).
  • A set of binaries, such as assemblies. This option is of primary interest to our .NET customers: they'd much prefer to download properly signed replacement assemblies that encapsulate the code fix. Of course, this is the option that requires the most amount of extra work for us, and if we can get away from doing it so much the better Smile.

So we've implemented another automated system. We're not quite sure what to call it yet -- the code name PublicCodeFix is a little boring -- but it's ready for beta testing.

The way it works under the hood is a little complex so I won't go into it here. However, how it's presented to you, our customer, is important, so let me go into that.

The UI is extremely simple: it's a button on the page for the issue in question. First of all, this button is only visible if the issue has been fixed. (To which we all go Duh!). It's also not shown if you don't have a license that is able to take advantage of the code fix. For example, if your license doesn't include source code, you won't see the button for a fix that alters your source code.

If visible, the button has three states. If the fix hasn't been generated yet, the button shows "Request Fix". If a customer clicks on the button in this state, a request is sent to support for the fix, and the button changes to "Requested". This indicates to other customers that the fix is being created and is on its way. You can click the button in this state and all that happens is that you get added to an internal list of people who want to be notified when the fix is available (the first requestor is obviously added to the same list). This list is essentially the tracking list that we already have. Finally, once we've prepared the files and the download package, we set the button to read "Available" and notify all the people tracking the issue that the fix is ready for download. In this state, you can click on the button and the fix is downloaded to your machine.

Of course, when the next version of the product is released containing the fix, the button will finally disappear for good.

We activated the PublicCodeFix application as a beta this morning so, if you see a fixed issue with this new button, you'll now know what it's all about. Needless to say, we'd love to hear your feedback about this new feature, so do please let us know using the usual support channels.

12 comment(s)
Nate Laff

Sounds great. Looking forward to trying it.

10 July, 2008
Rory Becker - DevExpress

Holy *^%&

Sweet mother of !"£$"£$...

That's so Cool

The IDE Tools team are really gonna hate me now. :D

10 July, 2008
Robert Thomas

Between this and the new CodeCentral that was released today, you guys just got tons of cool points in my book!  This will go a long way towards strengthening your already great customer service reputation.  Well done!

10 July, 2008
Chris W Walsh

sounds great Julian.

i was hoping to see a 4th tab in the Client Center for "Nightly Builds" for those who are interested in "beta" testing to help the development process along.

but all in all with this and CodeCentral great work guys.

10 July, 2008
grenzi_r

very sweet!

16 July, 2008
drew..

i just needed to say that this new feature ABSOLUTELY SAVED MY DAY. I had 2 required fixes the very next day, the day of delivery.... (cutting it very close ☺) . This feature is GOLD! and i don't CAP often..   drew..

ps: Julian: your discourse is centered on a "fix". I had 2 separate fixes to xaf that i requested. The next morning i had 2 notifications of availability of the fix. I took both down and compared and they seemed identical, which is what i wanted of course, as i wanted all fixes within one install. So my question: in fixes that are packaged as installs: are all current ready-to-go fixes incorporated into 1 download? In other words, we xaf folks don't have to worry about which fix we install in any particular morning?

Have a worded this in an understandable way?  thanks, drew..

17 July, 2008
Julian Bucknall (DevExpress)

Drew

Interesting question. At the moment, fixes are assumed to be fairly isolated so they don't intersect. I would imagine that if a fix requires another fix then (1) it'll take us longer to produce a patch, and (2) that patch would include both fixes. I dare say that if we found that too many of these were happening it would be time to release a minor update.

Cheers, Julian

17 July, 2008
Grant Argy

Julian in most cases DevExpress has been very good in fixing issues and that is great. A problem I face that relates to this blog however, is I found a bug in 9.1 that worked in 8.3 B135940. We have implemented a lot of new stuff from 9.1 in one of our products, but it is sitting on the desk waiting to rollout because the bug nearly one month later is not fixed. Now I know what it is like in the software development game, but it is a bit hard when you can't give any other feedback to your board other than they know it is a bug and we are waiting for a fix, but nothing more. If we were communicated that it will be a long way a way we might not like it, but then we can decide what we need to do. At the moment we cannot and when our product is used by around 2,000 customers and 10,000 users it can get painful. Appreciate if you can help me here. thanks Grant in advance.

19 May, 2009
ANTON SANTA

Hi Julian,

it would be great if there would be a list of all fixes available after last ufficial build. So we developers could decide if interested or not. Actually running into a problem I've to search in the knowledge base and/or report an issue (creating first a sample project) to hear from your (very good) support staff that there is just a fix available. It's time consuming for your staff and for me, too.

Ciao

Toni

27 October, 2011
Robert Smith

Julian,

I agree with Anton - a central location with a list of all available fixes since the last release would be a great addition!

Thanks!

- Robert

23 March, 2012
xavy xavys

who can help with this

Web buttons in ReportToolbar don't work nothin, for print, export

11 May, 2012
Tran Tuan 3

Hello.

I have code

=======================

Private Sub SimpleButton1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles SimpleButton1.Click

RichEditControl1.HtmlText = "<Table border=1><tr><td>tuantyteo</td></tr></table>"

Dim report As New XtraReport1()

' Get its XLSX export options.

Dim xlsxOptions As XlsxExportOptions = report.ExportOptions.Xlsx

' Set XLSX-specific export options.

xlsxOptions.ShowGridLines = True

xlsxOptions.TextExportMode = TextExportMode.Value

xlsxOptions.ExportHyperlinks = True

xlsxOptions.SheetName = "My Sheet"

Dim link As PrintableComponentLink = New PrintableComponentLink(New PrintingSystem())

link.Component = RichEditControl1

link.CreateDocument()

link.PrintingSystem.ExportToXlsx("test.xlsx", xlsxOptions)

Process.Start("test.xlsx")

End Sub

But when I run application

I  onclick. It error:</para>Object reference not set to an instance of an object.

code line: link.PrintingSystem.ExportToXlsx("test.xlsx", xlsxOptions)

Can you help me?

24 May, 2012

Please login or register to post comments.