On 16/01/2016 21:08, Ondrej Pokorny wrote:
On 15.01.2016 23:30, Howard wrote:
Sorry, my apologies - I missed that you didn't try it.
Yes working fine for me (Windows 7 32bit and Linux 64 bit).
I'm relieved that such a simple change has had such a good effect,
and that no further tinkering with TShadowMenu size and positioning
code was required; and that my poorly implemented scrolling code can
therefore be dumped entirely.
Yes, you must have wasted a lot of time on the extra scrolling code :(
+ Could you take a look also at this one?:
http://mantis.freepascal.org/view.php?id=29399
Basically you should use a simple parented TEdit and not a modal
dialog. Take a look at grids in-place editor.
I'll have a look later next week.
To me it seems that you have taken hard and complicated routes at a
lot of places in the new menu editor, which are very bug-prone, hard
to maintain and hard to understand - instead of using easy and simple
ways. As a result, you wasted your time and also mine and others that
tried to understand what's going wrong in the unnecessary code and
tried to fix it.
This is also the case of resource strings. Take a look e.g. at r51249
and r51305. Why was the dialog so complicated with duplicate strings?
Yes and No as answers are clear enough.
It stated:
"Deleting this item will delete all subitems too.
Delete this item and its subitems?"
You use the word delete three times, (sub)items 2+2 times. Why? (And I
don't count the dialog title and former buttons.)
Why not only the second line?: "Delete this item and its subitems?" ->
again it is clear enough. Furthermore, using the same words and
phrases over and over again is stylistically wrong.
In this particular instance of deleting a submenu (not just a single
item) my motivation was not to make it overly complicated (though I
appreciate it may seem so).
It is quite possible a user may have spent 10 minutes designing a
submenu with half a dozen items, and then hits the delete key
accidentally. With a simple Yes/No dialog (especially if the the default
button is Yes) it is all to easy to hit the wrong button and lose the
last few minutes' work; and there is no undo facility implemented.
I may have written that dialog clumsily, but I wanted to avoid the
possibility of an 'automatic' response which was disastrous. I quite
agree a straightforward Yes/No dialog is simpler and more elegant, but
it may not give a hurried user sufficient 'pause' to avoid accidentally
losing valuable work.
Honestly, the new menu editor is a translator's nightmare. Although I
do like what the new designer does, I don't really like how it is
written :( I tried to fix some code but I am somehow already tired to
go through all the issues.
Please don't get me wrong - I don't want to offend you in any way. I
just want to explain that you should use the KISS-principle whereever
possible. It will not only save everybody's time but also lead to
better code. (I know, I also have hard time to apply KISS.)
Ondrej
PS: Just for comparison:
BEFORE:
AFTER:
Even as a user, I need much more time to understand what's going on in
the first dialog...
No offence taken. I appreciate you taking the time to give constructive
feedback, as well as tracing through code you find poorly written in
order to improve it.
You'll realise I'm on a learning curve. This is my first significant
code contribution to an open source project. I actually never thought I
had the skill to offer a new menueditor. It was a forum comment by the
late BigChimp some years ago about the previous menueditor which first
got me thinking about its shortcomings, why it was so difficult to
improve/maintain, and how a replacement might be designed to be better
in that respect; and several developers said a complete rewrite was the
only way forward. Months became years and no one as far as I could see
was working on a replacement. So I decided to bite the bullet, and
started to look at relevant bits of the IDE code (much of which I still
don't understand). I've been learning on the job, as you plainly see...
Howard
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
