Sorry, I should have made it clearer that I wasn't speaking of Lc per se, but ui guidelines in general. Even then, my information is likely way out of date on the subject as the last time I was looking into it was around the Delphi 6 release time framejacque wrote:There's no recommendation per se, it all depends on the stack and how you want the UI to work.bogs wrote:I seem to remember the recommendation wasn't to hide them, but simply disable them, but I could be wrong.
Heh, I can well understand the 'nix philosophy, but I wasn't talking about sticking that in the buttons script. That kind of code would go much lower, card or, in the case of your address book where there are a LOT of cards, stack level script.chuckm wrote:I'm a bit hesitant to overload button handlers like that because it quickly turns into a bloated controller situation which can be quite hellish to debug. Small, modular handlers would seem to be a better approach but I'm new here. My Unix background also keeps popping up with the "keep each thing doing one thing" mantra.
I would point out that you could easily use the method I posted and still compartmentalize or further break down the code to specific handlers, the reason my psuedo code and the example I pointed to are in one handler is that it is just too simple to break down a lot further.
As well, at this point, we're just talking about an address book, unless you wind up turning this single program into a multi-program, like some huge desktop replacement, I just don't see the number of lines that would make this unmanageable coming around. I could be wrong though
Even if you eventually did decide to make this into a desktop replacement sized program, you could consider this address book as a module in itself, called from a completely different mainstack that is part of the larger program. Once it is thoroughly debugged/built/running on its own, it would be similar to a module in pascal or even assembler (the good ol days, right kids?). In other words, its working, all thats left is maintenance.
I would never suggest migrating everything to the stack or card level, but as much as is common in function I do. IF a button requires specific handling, I find it easier to put that code in the button, then pass the event for the handlers of common functionality to take care of at the lower levels.dunbarx wrote:If I tried to migrate as much as I could to the stack script, say, I do not think I would eliminate the work required to locate the appropriate handlers and functions.
I agree, it is a matter of style, I'd never suggest that it is the only right way, or even possibly the best way, I was only trying to illustrate a possible solution to the posed question