(I've wrote a long detailed post here, clicked Preview and this forum asked me to re-login. Lost 2 hours of work. )
I've changed some setting, after that:
... ME does not create any bugreport.txt in the exe folder nor any .mbr file on desktop at other PCs,
only on the developer machine !
It worked the first time on other PC too, with default settings.
Attached .mes file.
I'm changing the default path of all "Desktop" folder to E:\_DOK\Asztal
because users are copying sometimes more GB of data there, filling up C:\ .
Can be that a problem?
- MES setting file
- (2.41 KiB) Not downloaded yet
So, in my understanding madExcept created reports for anyone until then? If madExcept can't produce a log file in the location specified it will fail, period. That goes for any new file being created on a disk that may be full. My apologies in case I misunderstood what you meant.I've changed some setting, after that
If that's YOUR local folder, it works, otherwise likely not. A customer's folder shouldn't be specific to a single machine and not every customer has a mapped E: drive.E:\_DOK\Asztal
1. Yes, exactly! So it is clear: it has write access.So, in my understanding madExcept created reports for anyone until then?
(I always set up machines with full write access to it's own E:\TermiPRO\ folder, and it has write access to the desktop too, because it can save or export things with a "save as dialog"...)
2. So the big question remains: why did it stop creating logs after I have changed some settings?
3. I was hoping you have loaded / or looked at the .mes file I've attached, and tell me what setup point is doing that?A customer's folder shouldn't be specific to a single machine
I have the feeling you did not do that, otherwise you would see:
- I have NO fixed path set anywhere.
I'm a Delphi programmer since 25 years + I have 33 years of experiences about Windows, users, PCs, etc.
I think I have found a bug, or at least a "first time user experience failure", that's why I'm spending my weekend to write these posts.
Personally I like if my customers are reporting me everything, so I can improve myself.
PS: You can answer me in German language too, if it's easier to you. It's just faster for me to type in english .
Thank you for more information about a potential bug. My original quick reply were merely facts about drives and folders not existing on every client machine and the fact that a full drive does not allow for new logs to be created, this is why you've decided to redirect the Desktop path to the E:\ drive to a custom folder of your choosing. Yes, the million-dollar question remains as to why it worked before and now it does not work at all. Do you have an older settings file from before to compare to? With a simple "diff" we can spot the difference much more quickly. If not, we'd have to attempt to reproduce locally on our own machines, of course. We can't determine what settings you have modified (when it worked correctly) prior to failure.
As far as speaking German, I'm not 100% fluent. I speak English as my native language but also Czech and Spanish. I'm ok with English as you are, but I appreciate you attempting to take care of language barriers. Madshi will see this thread and see what he thinks, he's the madExcept creator =]
So there is nothing I could compare with myself, even, if I delete the .mes file and recreate it. That's why I've asked for help here.
It would be nice (and logical) if there would be +3 buttons next to the [ x ] Default checkbox at the bottom of the Setup window:
- [ Reset ] [ Import ] [Export]
- exceptions from inside `try ... except` are not captured by MadExcept.
- only not-handled leaks are reported.
Is there a way to force-report every each exception?
Import/Export is not really needed, the per-project settings are stored in the file named "yourProject.mes" (mes = madExceptSettings). You can simply copy the "*.mes" file.
You can use "RegisterHiddenExceptionHandler(YourHandler, stDontSync)" with your handler looking like this:
Code: Select all
procedure YourHandler(const exceptIntf: IMEException; var handled: boolean); begin handled := false; end;
I'm not sure what a "non-handled leak" is vs a "handled leak"? A leak by definition is "not handled". If an allocation is handled (= freed) then it's not a leak by definition. Or am I missing something?
Thank you for the detailed infos.
I will try it that way. (As soon as I've recovered from Covid.)
PS: Yes, it's clear: non-handled = leak = MadExcept will report it by default.
PS2: getting infos about ALL exception is just for dev.-testing, to see how much of my own try...excepts are swallowing errors and what kind of errors are they. An IF ... THEN runs ca. 20x faster than a handled exception.
Turned OFF [Map file] option (it was "Detailed" before).
- Re-Built the EXE, (I always do that, not just compile) and
- it actually did create a report on a foreign machine! [SUCCESS]
(I think the exe became a bit bigger too.)
Now, when I go back to Project>Options>Linker page, I see that after the build, the [Map file] is turned back on "Detailed".
So it seem MadExcept is doing something with this option, but maybe not properly. (Under Delphi-7). [bug?]
Usually I'm changing the Version number under Project Options. Tried to do that again for testing, but the Exe size remained now the same, so it did NOT causing the problem.
An other possibility I was thinking about is the russian "AlphaSkin" component, which is trying to repaint all popup windows, even msg. boxes, but the MadE. report window is Not painted (skinned), so I think we can rule that out too.
If I want to include MadE. into my app, I guess I'll be forced to put a hidden "error creator button" somewhere, so I can test if MadE. is working or not, before sending out new versions of my program each time... (one more extra step )
Since I've turned off my own global exception handler, to get reports from MadE.,
some tiny ( mostly .setFocus ) errors are making the life of many users miserable on daily basis,
so I have to think really hard if it would really help in any way, or cause even more trouble to include MadExcept in my program...
I will need more time + testing + time ... to finally decide if I want to buy this or not.
MANY thanks for the help so far!
If it happens that you find the error what can cause this and you can rule it out, so it never happens again, please send me a msg., because my answer will be a YES, since this is an awesome piece of module! (When it works.)
Cheers & Happy Coding!
I think you have misunderstood something. Please read topic subject.
I know that I could ignore some type of errors, but I don't want to.
I wanted that MadE. captures these errors. But it did not.
It did nothing.
I was refering to this part of your comment:
> to get reports from MadE., some tiny ( mostly .setFocus )
> errors are making the life of many users miserable on
> daily basis
You can solve this by ignoring specific exceptions that would otherwise make the life of many users miserable, which still having madExcept do its job for other types of exceptions.