Feature request: JSON format

delphi package - automated exception handling

Feature request: JSON format

Postby StephaneGrobety » Fri Nov 29, 2019 8:30 am

Hello,

I'm struggling a bit to integrate the crash report with our Azure Devops managment system. My main limitation now is that I cannot process the clear text crash report. In order to solve this (and facilitate integration with bug tracking software), I would like to sugges that the crash report attachement be (optionally) generated in JSON format. That would allow me to write sorting rules that could clear up a LOT of things:
- Auto-detect duplicate reports from different customers.
- Locat the code revision that caused the crash.
- Route the report to the correct module/team/team member.
- Auto-drop (some) allready corrected bugs.

XML would work as well but it's much less convenient to work with with the tools at my disposal (MS Flow and Azure Devops)
StephaneGrobety
 
Posts: 19
Joined: Tue Jul 17, 2018 9:21 am

Re: Feature request: JSON format

Postby madshi » Fri Nov 29, 2019 8:42 am

Well, you can use RegisterExceptActionHandler() to be notified when madExcept sends out a bug report, and in that case you can walk through the properties of the "exceptIntf: IMEException" interface to create any kind of bug report format you like.

Of course I could also do this within madExcept, but honestly, you're the first user who asks for this, and offering this as an option would increase the code footprint for every madExcept user.
madshi
Site Admin
 
Posts: 10156
Joined: Sun Mar 21, 2004 5:25 pm

Re: Feature request: JSON format

Postby StephaneGrobety » Wed Dec 04, 2019 8:53 am

Of course I could also do this within madExcept, but honestly, you're the first user who asks for this, and offering this as an option would increase the code footprint for every madExcept user.


Thank you for your answer. I have seveeral things to say to this:

1/ You switched to a subscription model to support the product (which is fine, really: I'm all for it). But this suggest that you intend to expand the feature set of the software as well as provide support to the existing code. In such a case, accepting feature requests from subscribers seems logical even if you don't get 20 requests for the same feature. Now considering there is no public "reature request" system in place, the argument "you're the first user who asks for this" seems pretty weak to me avdn eve counter-productive: assuming you implement it just for me and that I (or anyone else) uses that feature to provide clear direction to integrate ME bug reporting with Azure Devops (or github's issue tracking or Atlasian JIRA or any other), then it'll be an advantage for every other potential user.
2/ I can't fully perform the job on my own because the source code to recompile the devs tools (in particular, the viewer) isn't provided.
3/ I can see several ways of implementing this without increasing the runtime footprint for everyone that doesn't need it, really.
StephaneGrobety
 
Posts: 19
Joined: Tue Jul 17, 2018 9:21 am

Re: Feature request: JSON format

Postby slemmnord » Tue Dec 10, 2019 10:19 pm

I've been itching to say something along those lines as well but i don't want to piss Mathias off (and i really appreciate the work he has done so far). I do agree that keeping a product stable is a good goal. But with subscription model that is not enough (last new version was more than a year ago and had almost no new features). And there are many things that still could be improved. For example, various bug trackers support can be much enhanced. I think *modularizing* report sending system is a good idea moving forward. That way code for un-needed trackers (also e-mail which is unreliable) could be left out - thus reducing the code footprint. And modules could be developed further to work with various tracker systems specific features. Support for new systems could be added by third party even (current code is quite difficult to alter).
slemmnord
 
Posts: 40
Joined: Fri Jan 17, 2014 1:04 am

Re: Feature request: JSON format

Postby iconic » Wed Dec 11, 2019 1:51 am

Thank you both for being so patient. Mathias will reply as soon as he can, I assure you of this. He truly cares not only about the quality of his products but also about his user base and user feature requests.

--Iconic
iconic
Site Admin
 
Posts: 951
Joined: Wed Jun 08, 2005 5:08 am

Re: Feature request: JSON format

Postby madshi » Thu Dec 12, 2019 2:36 pm

Hey guys,

sorry for the late reply.

I understand your comments about subscription suggesting regular updates and improvements. And I agree. But in order to put it in perspective a bit, please allow me to mention that I've intentionally set the subscription rate rather low because I knew in advance that I didn't plan to add a lot of new features and would mainly do support and maintenance. So e.g. if you compare madExcept's Single Developer License subscription rate of 49 EUR per year to that of my competition, their subscription rate (of their Single Developer Source Code license) costs 124.50 USD which is about 112 EUR. So it's more than twice as expensive. If you think about it, 49 EUR per year is just 4 EUR per month. That's really not a lot.

(Company rates are higher, of course, but still quite modest.)

Anyway. I fully understand and support your desire to have better support for uploading bug reports to various error/exception reporting websites/database/tools. So let's talk about how to achieve that in the best possible and most efficient way:

I guess I could/should refactor the current BugZilla/Mantis/FogBugz code into one (or multiple) separate unit(s). And maybe think of ways to make it possible for you to add support for other bug trackers yourself with less effort. Does that sound good to you? One potential problem I see is that seemingly every one of these bug trackers have their own private API set, and they all differ greatly. So adding support for more bug trackers isn't going to be easy in any case. And there may not be much code that can be shared.

I guess I could add an extra unit which contains a function which converts an "IMEException" interface into XML or JSON. This side of the processing should be relatively easy. I'm concerned about the other way round, though: Would you also require me to parse such XML/JSON bug reports, e.g. for the madExceptViewer application?

Thoughts?

P.S: The source code of the viewer *is* shipping with madExcept, see "madExceptViewer.dpr".
madshi
Site Admin
 
Posts: 10156
Joined: Sun Mar 21, 2004 5:25 pm

Re: Feature request: JSON format

Postby slemmnord » Wed Dec 18, 2019 2:28 am

Hi Mathias,

madshi wrote:I understand your comments about subscription suggesting regular updates and improvements. And I agree. But in order to put it in perspective a bit, please allow me to mention that I've intentionally set the subscription rate rather low because I knew in advance that I didn't plan to add a lot of new features and would mainly do support and maintenance. So e.g. if you compare madExcept's Single Developer License subscription rate of 49 EUR per year to that of my competition, their subscription rate (of their Single Developer Source Code license) costs 124.50 USD which is about 112 EUR. So it's more than twice as expensive. If you think about it, 49 EUR per year is just 4 EUR per month. That's really not a lot.

And only 13 cents per day.. :P
I think it is still hard to justify from customer point of view if you're planning to only do essential fixes (i'm assuming here), add packages for new compiler versions and do support.
I imagine new customers require most support effort after having bought a new license and starting to integrate ME with their projects (or some times even before buying). And after some initial learning curve most wont bother you at all or very rarely. Is that something you can confirm?
Assuming above is true, why would someone keep paying for something they already have?

In my case, i am still using Delphi 7. So adding support for newer compilers is of no immediate interest to me. I rarely require support now. Most questions i have, i solve by looking into source code or searching here in forum. I report findings and ideas mostly to let you know what could be useful "out there" and to help fix bugs in ME.

madshi wrote:Anyway. I fully understand and support your desire to have better support for uploading bug reports to various error/exception reporting websites/database/tools. So let's talk about how to achieve that in the best possible and most efficient way:

I guess I could/should refactor the current BugZilla/Mantis/FogBugz code into one (or multiple) separate unit(s). And maybe think of ways to make it possible for you to add support for other bug trackers yourself with less effort. Does that sound good to you? One potential problem I see is that seemingly every one of these bug trackers have their own private API set, and they all differ greatly. So adding support for more bug trackers isn't going to be easy in any case. And there may not be much code that can be shared.

Well i would be really happy if you did something like that. I can only assume other users would find it useful as well. Searching for "Mantis" in forum gets 12 pages of hits. Probably same amount in the newsgroup (your news server is down btw). Delivery of report is important feature.
If specific tracker support is in own unit then users could customize and extend support more easily. This would surely lead to you receiving such enhancements as contributions which would benefit all other users with little further effort from you.
Supporting more trackers would also be great but that is a bonus goal. One where you might also get code contributions once there is an easily extendable interface.
I chose Mantis because the choices were limited by what ME supports. There are better free options now. And the choice depends on nature of project too.

madshi wrote:Thoughts?

If you want to feature freeze the product and move on to other more interesting stuff then that is fine. This is in conflict with subscription model. No matter how cheap the price.
Or you could run a questionnaire and ask your users what they want. Which features are they missing. What is bugging them most. Probably an endless list of ideas for changes would result which would help justify renewing subscription. Likely even with higher fee. Your competitor seems to be releasing around one or two new versions each year with quite a few new things each time. At one point potential new customers might find competing product ticks more of the boxes they need ticked. In that case 100 here or there is non-issue.
Obviously only you can judge if investing more of your time is worth it (see here). These days, Delphi is clearly a niche compiler with uncertain future and waning user base.
In whatever way forward you deem best, i think your intent should be indicated near subscription price and description so people know what to expect.

Regards,
SN
slemmnord
 
Posts: 40
Joined: Fri Jan 17, 2014 1:04 am

Re: Feature request: JSON format

Postby madshi » Wed Dec 18, 2019 10:18 am

I didn't mean to say that I wanted to "freeze" the feature set and never do any improvements/new features, anymore. Actually, I do plan to rework the GUI to make it look more like a standard dialog, and with improved support for high DPI. And improving support for sending bug reports to bug trackers certainly sounds worthwhile. It's just that I can't think of any *major* new features that would be missing. Because of that I set the subscription rate fairly low.

Anyway, I'm planning a new release for January (or early February), and I'll add refactoring of the bug report sending (to bug trackers) to the list of things to do. Also, I'll not actively ask for subscription renewals until the new release is out.
madshi
Site Admin
 
Posts: 10156
Joined: Sun Mar 21, 2004 5:25 pm

Re: Feature request: JSON format

Postby slemmnord » Sun Dec 29, 2019 1:59 am

madshi wrote:I didn't mean to say that I wanted to "freeze" the feature set and never do any improvements/new features, anymore.
I got that impression but i'm happy to be wrong.

madshi wrote:Actually, I do plan to rework the GUI to make it look more like a standard dialog, and with improved support for high DPI.
Do you mean the standard exception dialog? If that's the case then i'm all for it. I do not like the standard one and designed a custom one for both exception display and bugreport sending with more native styling. Using VCL so it is only for main thread but that covers 90% of cases. So close enough.

madshi wrote:And improving support for sending bug reports to bug trackers certainly sounds worthwhile. It's just that I can't think of any *major* new features that would be missing. Because of that I set the subscription rate fairly low.
More platforms maybe -- Mac/Linux/Android? Just a thought (i don't need any of that). Combing thru or polling this forum will probably give more ideas.

madshi wrote:Anyway, I'm planning a new release for January (or early February), and I'll add refactoring of the bug report sending (to bug trackers) to the list of things to do. Also, I'll not actively ask for subscription renewals until the new release is out.
Sounds good! I should be on your mailing list so i'll wait patiently :)
slemmnord
 
Posts: 40
Joined: Fri Jan 17, 2014 1:04 am

Re: Feature request: JSON format

Postby madshi » Mon Dec 30, 2019 11:53 am

More platforms would probably be very difficult because I know nothing about Linux, MacOS etc.

Would you mind posting a screenshot of your VCL dialogs? Maybe that could serve as a little inspiration for me... :D
madshi
Site Admin
 
Posts: 10156
Joined: Sun Mar 21, 2004 5:25 pm

Re: Feature request: JSON format

Postby slemmnord » Mon Dec 30, 2019 8:05 pm

Sure, I don't mind. I simplified it compared to standard ME error dialog as end-users don't need to view the report and too many options is confusing. The error dialog is a windows task-dialog with extra checkbox and button. For XP where task-dialog does not exist I'm using MessageBoxIndirectA where same result can be achieved (extra btn and checkbox). Those could probably even be made thread-safe (issue is likely with disabling main thread forms).
The report sending window is a VCL window styled the same as rest of application windows (bottom line and buttons below in right-side). I wanted to have all the inputs in one window. After clicking ok, the report would get sent with no further questions.
Untitled2.png
Untitled2.png (11.8 KiB) Viewed 1474 times
slemmnord
 
Posts: 40
Joined: Fri Jan 17, 2014 1:04 am

Re: Feature request: JSON format

Postby madshi » Fri Jan 03, 2020 8:41 am

Thanks! How would you change the design to make it possible to look at the bug reports details? Might not be useful for the end user, but on the development PC, I think many developers would like to be able to directly look at the bug report, and not be required to send it first, before they can look at it?
madshi
Site Admin
 
Posts: 10156
Joined: Sun Mar 21, 2004 5:25 pm

Re: Feature request: JSON format

Postby slemmnord » Wed Jan 08, 2020 2:38 am

I agree, that would be useful. I think "Restart" is not necessary for developer doing testing so that button could be changed to "View report" when compiled in debug mode or maybe when holding down shift key (bit hacky, i know).
Another option would be to have report view tab or button in the sending window.
slemmnord
 
Posts: 40
Joined: Fri Jan 17, 2014 1:04 am

Re: Feature request: JSON format

Postby madshi » Wed Jan 08, 2020 2:39 pm

I think the most important buttons for an end user dialog would be "close" and "continue", no? I didn't even notice you had a "restart" button in there. But that's the problem right there: There are many different things that might be useful, which is why my default dialog isn't great, because it allows you to add all those buttons like close, restart, continue, show bug report, send bug report. Adding so many buttons is hard without convoluting the user interface.
madshi
Site Admin
 
Posts: 10156
Joined: Sun Mar 21, 2004 5:25 pm

Re: Feature request: JSON format

Postby slemmnord » Wed Jan 08, 2020 8:08 pm

My thinking was that first, most important is convenience for end-user, not developer. And second that user is most likely not yet done doing whatever he was trying to achieve and wants to continue (else app would not be running). Thus "continue" is selected by default. But some class of errors keep re-appearing after first time so "restart" option is stronger option for same thing.
I think this intent to continue can be assumed for most errors. Only exception being an error when closing the application.
That case can easily be handled by setting some flag when starting closing procedure (to show only "close" button on subsequent errors). Easily doable by the developer and appropriate place to set such flag depends on app design (no need to hook main form close or app.terminate by ME).

An option to consider is various extended task dialog possibilities. TaskDialogIndirect allows for great deal of control and interactivity.
https://docs.microsoft.com/en-us/window ... s-overview
https://docs.microsoft.com/en-us/window ... sk-dialogs
This would mean ditching XP support of course.
slemmnord
 
Posts: 40
Joined: Fri Jan 17, 2014 1:04 am


Return to madExcept

Who is online

Users browsing this forum: No registered users and 6 guests

cron