|Débuté par ccc2, 14 mai 2018 13:50 - 10 réponses|
Posté le 14 mai 2018 - 13:50
is gui error useful . to me most of time is just generate necessary noisy .
Posté le 16 mai 2018 - 02:32
On my side, it's always on, and never a hassle, as I correct the errors as soon as they are displayed, like all other compiling errors.
My target is to ALWAYS have an empty list of errors and warnings in all projects... And if you work on each individual small problem as soon as you get a message, it's very easy...
An advantage of working like that is that any NEW problem is immediately clearly visible (and therefore easy to correct), as it is not swimming in a sea of old, non corrected ones.
Posté le 16 mai 2018 - 08:43
you can switch off the GUI errors and that's it. Sometimes it gives hints to badly designed controls, to short-spaced controls for captions ..
Posté le 16 mai 2018 - 14:05
If it generate what you consider unnecessary noise, it means, in my experience, that your UI is full of problems that you should definitely look at...
Posté le 16 mai 2018 - 15:48
Yes, it's very useful, but there is a lot of noise. At some point during the dev lifecycle you'll need to consider the issues raised and I think what you're getting at is that you need to "filter" all that "noise".
I tend to review the GUI "noise" periodically because it's a hassle having to re-build the project every time you switch it on/off.
Posté le 16 mai 2018 - 22:38
if I start a new project, I do the analysis first. I f that looks 95% fine then I let it run a full project RAD. I have to because we're using RAD11 / MDI as a standard and this is the only way to get MDI windows when generating a new window for the project. This RAD run generates about 200 to 300 windows AND about more than twice of that number in GUI errors. So, I can understand ccc2's complaint.
But. The GUI errors tell you things you woudn't get from warnings and compilation errors. It tells about double shortcuts on a window, double links to file items. It's possible to switch off the most annoying ones (e.g. "the caption in German doesn't fit a control") which is sometimes true, but not very often.
Posté le 17 mai 2018 - 12:33
I not sure about others the detection problem getting worse when you upgrade project from previous version.
on 100++ report it prompt text size too small . what the is gui compiler problem , all report show correct (no overlap ) and print out correct . if i change then it will be wrong . tell me what should I do to satisfy gui compiler?
Posté le 17 mai 2018 - 12:43
As you know, I'm not using the RAD, so I don't have your problem, but I would have thought that rule 1 in your cookbook would have been to remove all the GUI problems, so that the field is clear for more important problems... Again, maybe it's just me.
I'm pretty sure that the error message is not simply 'text too small', as error message have a tendency to be much more verbose, so I wont be able to help you with so little information.
Posté le 17 mai 2018 - 16:01
Hi Fabrice, yes, it's rule zero :cheers: ... the cook book deals with each type of the RAD windows and of course, one should leave a window only after all errors are gone. We do not delete all errors in the project from start because full app RAD generates lots of windows and reports which aren't needed at all. Fixing of errors in windows which would be deleted anyway is not a sensible way to deal with precious work time ...
However, what I wanted to say is that RAD11 produces hundreds of GUI problems on its own ... ok, it's from times without GUI errors, excused ...
Posté le 18 mai 2018 - 08:09
I found another bugs when upgrade from older version of wd project
item control "link to " if leave blank will cause problem cause in new version blank will be treated as <not found or not compatible > where it suppose to be treat as <none>
Posté le 18 mai 2018 - 21:56
I think GUI errors are very helpful. I keep them on all the time and fix them all before moving on. They help keep the app more user friendly. For instance, I often copy a button or other control, modify it, but forget to modify its help to comply with its new function. GUI error wakes me up. Also it wakes me up if the control's prompt is too short in one or more languages. Small things like that, but very important for the user.
But it is true that in some cases there may be a devastating amount of "errors", especially when upgrading an old app to a new WX version. But then I just have to take the time and fix all of them. Also, as I am using templates a lot, they always generate some "default" errors when some variables are referred in the template code, but not really in there until they are added in the generated window manually. These I just turn off.