madshi wrote:So in the next build, [...] things will work as you expected.
madshi wrote:You might not like attachments, but I think you're pretty much in the minority there.
madshi wrote:If my exception box were VCL, it could not be used in situations where the main thread is "frozen" (e.g. in an endless loop without message handling, or in a deadlock).
madshi wrote:If you think that madExcept is not high quality, why are you using it?
madshi wrote:But it seems a win32 standard "look" is more important to you than a reliable exception catching functionality.
Tahtu wrote:Because other implementations are more bad.
madshi wrote:I'm not sure I want to change the installer.
madshi wrote:My experience with standard installers isn't really all that great, anyway.
madshi wrote:Also my installer has some features which no other installer has
madshi wrote:In win9x etc there was an old help file format, I don't even remember the name.[/qoute]
Yes, I remember it. Imho it was better than the .chm format.
But people are knowing the .chm format and the HtmlHelp Viewer. Since they know it, they feel good using it. And you develop the software for them - not for yourself.madshi wrote:At some point I considered using it. If I had, it would have been a catastrophe because current Windows versions are not even able to display it, anymore.
I used "Help & Manual" at that time too, I wrote my WinHelp file with Help & Manual. And while MS published the .chm format, all I had to do was updateing Help & Manual, choosing an other output format - done!
Because of this, it's important to use standard software. They will be updated.
I'm developing software in Pascal / Delphi since 30 years. All I learned in Pascal, I still use it today. I uses standard software...madshi wrote:I don't think file size is too important these days.
This is a question of respecting the resources of other people and the world: Smaller file size is reducing internet traffic and making downloads faster. I offer bugfixes often. My download size is 5 MB. So the people, who updating their software often, are happy to get the update faster - and the internet does not have to handle unneeded traffic.madshi wrote:But anyway, I don't really know how to improve that.
Ok, this point I understand. Working too much time of reducing the file size is not a good solution. I don't know your software. So I can't assist you in this point. But I know the overhead of madExcept is 30 % more than the overhead of EurekaLog 6. So there must be a way to reduce the file size.
I think a solution could be storing lesser informations of the map file. I think there are a lot of information, which are not needed in the ready published program. But maybe I'm wrong in this case - it's up to you to find a solution for this...madshi wrote:I could increase the compression of the map file information,
I compare the file size of my ready compiled (public) setup program. InnoSetup creates this, with a very good compression, I think. So I think, the compression is not the point.madshi wrote:I could try to reduce the madExcept source code size, but that's hard to do without losing features.
I read a lot of your help documentation. I didn't found a lot of unneeded or redundant information there. Because of this, I think you are able to do what is needed - an not too much. I have the same impression in the features of madExcept. So I think you program code is also good - not too much. Because of this, I don't think this is the solution too. But again: I never read you source code - so I can't know it.madshi wrote:I'm not sure if there's much more I can do about it.
madshi wrote:I have thousands of customers.
madshi wrote:Based on all the feedback I've received in the past[/qoute]
Again: Not the users who found you are important. The users who didn't find you or who didn't contact you are important.madshi wrote:1) effectivity in finding bugs
2) good end user experience
3) ease of daily use (not ease of installation)
You realized this features. So now you can take a look to the parts, you didn't realize until now.madshi wrote:I believe installer experience and help file format is WAY down the priority list for most madExcept devs.
Feeling good it the highest priority for the very most humans. And they feel good, if they find what they know.madshi wrote:At least that's my impression from all the feedback I'm receiving.
Yes, I believe this. But this is not how you can become more public and how you can get more users.madshi wrote:I think your priorities don't really match the majority of the madExcept users
Yes, I agree with you!
Users with my priorities looking for their whiches at EurekaLog, since thier look and feel promise much more, than your look and feel promises. But the promises of EurekaLog will not be fulfilled by that software.madshi wrote:Except for "good end user experience", of course (e.g. high-DPI-awareness etc), where I agree with you.
madshi wrote:I'm not sure I want to change the installer. It probably isn't ideal, but it does the job, and it includes all the key file logic etc. I'd have to invest a lot of hours to implement all the same features into a "standard" installer,
madshi wrote:I would love to have separate installers for madExcept and madCodeHook
madshi wrote:The user/dev might even install an old madExcept version and a new madCodeHook version.
madshi wrote:madCodeHook by default comes without source code.
madshi wrote:So it's an important protection
Users browsing this forum: No registered users and 3 guests