[Lazarus] disabled vs readonly TDatetimeEd
Hi: (Just a little off topic about TDatetimeEd) After deep thoughts about how I use readonly and enabled;-) I have Concluded this: enabled:=false > Invisible readonly:=true > Label Enabled When I set a control to enabled:=false, it's because i think the user shouldn't see or care about that control. A common use is speedbuttons . Some times depending upon some selection, some controls have no sense, i.e.some checks or radio buttons disable other controls. For all purposes those controls could be invisible. Why do I disable them instead of setting visible:=false? Most times because there would be a lot of ugly blank spaces (or in autoaligns would move other controls, confusing the user), some times because I'm waiting some data before letting the user fill the disabled controls, and it's not bad to let user see whats going on. Readonly I could say that most times I should use a label but I am too lazy. I have made a form to input data, and I want to reuse the same form to display the data. Some times there are controls that I want dynamically set to readonly, contrary to disable the controls, the information shown is relevant for the user, but I don't want him to change it. The only difference with a label is that it looks like a control, so the user knows that in some circumstances he could change the data. That is what I want to do, but things are not always that easy and clear . When there are controls readonly and not readonly in a form, they look the same so it's confusing for the user. To prevent this, sometimes I change the background to the form's backgound, others I replace it dynamically with label, other times I don't set it readonly but when the user tries to change it I pop message saying why he can't change it. I have seen (but I don't like) chekbuttons disabled, because they must be checked or unchecked compulsorily. I think it is not a good idea, if it is disabled the user could skip it as irrelevant. Of course, it would be handy a way to show clearly that it is not editable. Unfortunately, most GUI lack of such concept, so we would have to come out with something new, that is seldom a good idea when talking about interfaces. If it is not a very clear "metaphor" instead of helping the user we will confuse him. Just my 0.10 cents. Santiago A. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] for Michael A. Hess
Hi Michael, My messages is blocked on lazarusdev, can you please look! Thanks -- Laurent. My Components: http://wiki.lazarus.freepascal.org/Wile64 French Forum : http://lazforum-fr.tuxfamily.org/index.php ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Gif support in OpenPicture Dialog
Hi all, Does the OpenPicture dialog use TGraphic to build up the list of supported image files in the filter property like in Delphi? thanks, Dominique, ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FYI: Shared Libraries support
Hello, I don't understand the issue. As Razvan writes, isn't it an OS issue? For example, please find attached a small but complete example I've scratched together this morning to show how one can use DLLs in Windows. Obviously, a minor variation of the code could easily be done for the various linuxes. FPC and Lazarus therefore do have the capacity for dynamic loading of DLLs. It may be the compiler could add some syntactic glue, but nothing a competent programmer cannot do on his own with minor work, or encapsulate within a component. See the example. I guess GLScene is doing it already. Or is there something I have missed here? Best regards, Thierry Coq Razvan Adrian Bogdan a écrit : > On Linux they used the OS abilities and naming rules to prevent a dll > hell, since a typical Linux system contains at least twice (usually > much more) the number of libraries and applications than your windows > machine, if you have a 64 bit Linux you will see how nice libs are > placed and with simple symlinks and version in .so names, there are > absolutely no naming conflicts, still with all binaries in one place > it manages to avoid the dll hell and make everyone happy. > I assume OSX also played it smart but OSX had more planning in the first > place. > The only platform with dll hell is windows, because it didn't support > any type of links until NTFS hard links that few know about or use, on > windows Borland was smart enough to include versions in their .bpl > files for each Delphi version, maybe M$ should have folowed the > example instead of inventing a squared iron wheel covered in rubber > named an "assembly" that tricks your app into dynamically loading > whatever dll the user wants you to load, can't we implement such > mechanism ourselvs. > I like the way Zeos Components make use of such dynamic loading and > use different dlls and could even have multiple versions of the same > dll loaded at once and change between those at runtime, it is a simple > as creating a record structure holding the dlls functions and making > instances of this record and dynamically loading every version of the > dll, it is even more advanced than the assembly concept because you > can chose from the application what dll to load and even use more than > one version of it. I think FPC could make dynamic dll loading using > the current static dll loading syntax or very similar syntax if you > are too lazy to write a dynamic loader but then again how much use > would it have to have almost the same syntax, maybe it would help > automatic converters. > > Razvan > ___ > Lazarus mailing list > Lazarus@lazarus.freepascal.org > http://www.lazarus.freepascal.org/mailman/listinfo/lazarus > > > ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
