Re: [DUG]: I've had it up to here with TEdit descendants
- Original Message - From: Max Nilson <[EMAIL PROTECTED]> To: Multiple recipients of list delphi <[EMAIL PROTECTED]> Sent: Monday, December 20, 1999 3:20 PM Subject: RE: [DUG]: I've had it up to here with TEdit descendants > Trevor asked: > > > ...and I'm sure that I'm not the only one. > > Your not 8-) > > > Is it just me, or is any decent entry field necessarily descended from > > TCustomControl? Hey, is TCustomControl even a good place to start? > > TCustomControl is the perfect place to start building your own collections > of edit controls that work exactly as you want them to. The Profax team > has built replacements for every single data entry control we needed for > our accounting package, and we have not regretted it one bit. > Thanx Max, I don't know if I'm parrotting someone's marketing slogan, but having taken the plunge, IT JUST FEELS RIGHT. Thanks also for your CM_CHILDKEY pointers, another of those things that I didn't even know existed yet is likely to provide exactly what I need. And now going WAY offtopic, I'm a Pascal boy from way back yet from time-to-time have been forced to write in C. With the standard C runtime library, it is easy to create a file, read a file or write to it, but to delete it would you have thought of "unlink" as as function name? Do newbies even stand a chance? --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
Re: [DUG]: I've had it up to here with TEdit descendants
- Original Message - From: Neven MacEwan <[EMAIL PROTECTED]> To: Multiple recipients of list delphi <[EMAIL PROTECTED]> Sent: Monday, December 20, 1999 4:25 PM Subject: Re: [DUG]: I've had it up to here with TEdit descendants > Trevor > > Funny but I've just been contemplating the same thing > What I'd like is an input masking system that handled money/dates/times etc > > I've used the Softouch as a basis for one control (cause their calendar > control didn't input times) > Their code is quite nice and derives from TCustomEdit, supports 'popups' and > floats over grids! > > So if you come up with anything I'd be interested > Neven, I'm interested in what you've done. I have created a Time edit which I based on a Softtouch thingummy, I like the grid float feature, and also the popup support, but had HUGE problems when implementing a slightly more sophisticated popup child which itself contained other controls. Time constraints (app delivery, not TControl) prevented me from addressing these in an elegant fashion, but I will definitely revisit. I'm still convinced that the basis of all my problems is the TEdit that everything else is based upon. Having got as far as I have, I feel like I have a tiger by the tail...everthing seems to be working so much better now that Windows has minimal influence yet I can't help thinking that the original designers can't have been too bad to have come up with something that has lasted so long. BTW, my grid-parent capable control for time editing has an analog clock popup with draggable hands and a precision property (nearest 5 mins, 15 mins etc) Did you find you needed those features? --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
Re: [DUG]: I've had it up to here with TEdit descendants
> The Topaz Delphi database (.dbf) library is also advertised as having really > good edit mask capabilities (compatible with the old DBase way of doing it). What I'd like to see is a MaskEdit-type thing with a RegExp mask interface (instead of Delphi's blank-digit-digit-blank style mask, which is pretty much useless). Anybody know if one exists? As for the idea of a repository for replacement edit controls and stuff, why not start one? I'd be keen to see it, and even to contribute if I could... - Matt --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
RE: [DUG]: I've had it up to here with TEdit descendants
Trevor asked: > ...and I'm sure that I'm not the only one. Your not 8-) > Is it just me, or is any decent entry field necessarily descended from > TCustomControl? Hey, is TCustomControl even a good place to start? TCustomControl is the perfect place to start building your own collections of edit controls that work exactly as you want them to. The Profax team has built replacements for every single data entry control we needed for our accounting package, and we have not regretted it one bit. > So far, I've some good entry field controls working. They > exhibit none of the "why does it do that?" kind of behaviour > that inbuilt Windows descendants have. Several have popup- > helpers (also descended from TCustomControl) like calendars, > numeric keypads etc. Ditto, once you toss the baggage of the basic windows controls you have complete freedom to innovate and create control that perform things that would be impossible with the basic windows controls. People should remember that the basic windows controls were written years ago (Windows 3.0 or earlier), were not designed for serious business data entry, and have not been changed much over the various windows versions. > Problems to date that I think someone else may have solved are: > > a) Helper controls show up when some kind of focus rule is imposed, but > since they almost always have their parent handle set to 0 ( with > Windows.setparent( helper.handle, 0 ) to avoid clipping, they actually > appear as a blank button on the taskbar! Does anyone know of > an easy way to avoid this? We keep the our popup control parented to the editor, and clear the WS_CHILD style bit and set the WS_POPUP style bit so that the control appears to float over the top of the rest of the application. This works perfectly for everything that we have wanted to do so far. > b) Some of the helpers are swallowing keystrokes...they > respond to WM_CHAR and WM_KEYUP messages, and set Msg.result > appropriately, but other keyboard handlers in the near > vicinity ( Form.keypress etc) don't seem to get a look > in, AND ITS ONLY SOME KEYS AARGH! You have to be careful here, as many keypresses are intercepted by Delphi and used for navigation. Have a look at the event loop and associated routines in Forms.pas, because lots of keys eaten in there. We solved this issue by having our own hierarchy of control process the CM_CHILDKEY message which is automatically passed from child control to parents until processed, and allows correct "overriding" of default keyboard behaviour during extended editors getting keys and the like. > c) Double-clicking somewhere in a helper (this is a TCustomControl > remember) seems to set some kind of focus flag somewhere, so that if the > helper contains other controls, _one_ of them will receive all mouse and > keyboard messages, whether or not it is vaguely interested in them. The problem here is that from Windows point of view there must a window (that is a window Handle) that is the current focused window for key presses. So you have a choice of how to build your controls, either have your helper window passed unneeded messages up to their parent for correct processing (see CM_CHILDKEY comments above for some of the solution), or build you helper control from descended TGraphicControl, not TCustomControl. By starting at TGraphicControl you are creating controls that don't have a windows handle, but can be parented to a handled control and these provide the helper visual appearance, don't grab the focus, and are very elegantly supported by Delphi. > If you've been there and solved some of these > problems, I would love to know either i) that you did it (and snicker > snicker aren't letting on how) ii) that you did it and here's how, EMail me if you want more advise on how we replaced all the Windows control, because it possible, we've done it, and its part of the competitive advantage our software has over the other products in our market place. When you compare control designer for accounting data entry to what you can build based on the Windows controls you can really feel the positive difference in the ease of data entry, and the programmer's are happy because we can fix any problems, and enhance the controls with very minimal effort now. > or iii) its impossible, give in and let M$ control the world, NEVER! > iv) that there is a project somewhere wherein Delphi developers can > create controls that actually work and I should be contributing, Not that I have ever heard of. > v) that there's actually a good library available out there somewhere > (source included) which does this stuff. We looked and gave up. All other libraries start with the basic windows edit control (usually from TCustomEdit) and try and add all the features that are necessary. To do this you have to work about some seriously perverse design issues with the basic Windows edit control, the crap Windows default keyboard handling, and if you use data-aware con
Re: [DUG]: I've had it up to here with TEdit descendants
The Topaz Delphi database (.dbf) library is also advertised as having really good edit mask capabilities (compatible with the old DBase way of doing it). It may be overkill in that it also has the database stuff added... They have a specific point on their FAQ regarding this. See http://www.softsci.com/topazfaq.htm#26 Xander - Original Message - From: Neven MacEwan <[EMAIL PROTECTED]> To: Multiple recipients of list delphi <[EMAIL PROTECTED]> Sent: Monday, December 20, 1999 4:25 PM Subject: Re: [DUG]: I've had it up to here with TEdit descendants > Trevor > > Funny but I've just been contemplating the same thing > What I'd like is an input masking system that handled money/dates/times etc > > I've used the Softouch as a basis for one control (cause their calendar > control didn't input times) > Their code is quite nice and derives from TCustomEdit, supports 'popups' and > floats over grids! > > So if you come up with anything I'd be interested > > The best mask syntax i've seen is the Infopower 'PictureMask' which was > based on the paradox 'PictureMask' > but the rest of the stuff was relatively horrible once you got past the > surface > So if there was a CustomEdit based component that implememented a paradox > mask (with good source) > it would be somewhere to start > > Regards > Neven > > > > -- - > New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] > Website: http://www.delphi.org.nz > > --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
Re: [DUG]: I've had it up to here with TEdit descendants
Trevor Funny but I've just been contemplating the same thing What I'd like is an input masking system that handled money/dates/times etc I've used the Softouch as a basis for one control (cause their calendar control didn't input times) Their code is quite nice and derives from TCustomEdit, supports 'popups' and floats over grids! So if you come up with anything I'd be interested The best mask syntax i've seen is the Infopower 'PictureMask' which was based on the paradox 'PictureMask' but the rest of the stuff was relatively horrible once you got past the surface So if there was a CustomEdit based component that implememented a paradox mask (with good source) it would be somewhere to start Regards Neven --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
Re: [DUG]: I've had it up to here with TEdit descendants
Have you checked out Orpheus from Turbopower? Or did that piss you off also? I haven't used it since Delphi1, but it was pretty damned impressive then. If you haven't tried it, then suggest you download the demo from www.turbopower.com. I'm Interested to here what you settle on eventually. Cheers... -Original Message- From: Trevor Jones <[EMAIL PROTECTED]> To: Multiple recipients of list delphi <[EMAIL PROTECTED]> Date: Friday, 17 December 1999 21:01 Subject: [DUG]: I've had it up to here with TEdit descendants ...and I'm sure that I'm not the only one. Problem: I need a really good numeric entry field which can be set to accept either integral values or non-integral values with a specified precision Potential solutions: Scan the Net for TCurrencyEdit kinda things, try each, discover HUGE shortcomings, and start again (and again..). Is it just me, or is any decent entry field necessarily descended from TCustomControl? Hey, is TCustomControl even a good place to start? So far, I've some good entry field controls working. They exhibit none of the "why does it do that?" kind of behaviour that inbuilt Windows descendants have. Several have popup-helpers (also descended from TCustomControl) like calendars, numeric keypads etc. Problems to date that I think someone else may have solved are: a) Helper controls show up when some kind of focus rule is imposed, but since they almost always have their parent handle set to 0 ( with Windows.setparent( helper.handle, 0 ) to avoid clipping, they actually appear as a blank button on the taskbar! Does anyone know of an easy way to avoid this? b) Some of the helpers are swallowing keystrokes...they respond to WM_CHAR and WM_KEYUP messages, and set Msg.result appropriately, but other keyboard handlers in the near vicinity ( Form.keypress etc) don't seem to get a look in, AND ITS ONLY SOME KEYS AARGH! c) Double-clicking somewhere in a helper (this is a TCustomControl remember) seems to set some kind of focus flag somewhere, so that if the helper contains other controls, _one_ of them will receive all mouse and keyboard messages, whether or not it is vaguely interested in them. I'm bound to pursue this approach for my entry fields 'coz a, b and c aside, the controls are much better behaved than any of those which re-introduce standard windows behaviour, and are inherently able to operate in a flicker-free fashion. If you've been there and solved some of these problems, I would love to know either i) that you did it (and snicker snicker aren't letting on how) ii) that you did it and here's how, or iii) its impossible, give in and let M$ control the world, iv) that there is a project somewhere wherein Delphi developers can create controls that actually work and I should be contributing, v) that there's actually a good library available out there somewhere (source included) which does this stuff. Here's hoping Trevor --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
[DUG]: I've had it up to here with TEdit descendants
...and I'm sure that I'm not the only one. Problem: I need a really good numeric entry field which can be set to accept either integral values or non-integral values with a specified precision Potential solutions: Scan the Net for TCurrencyEdit kinda things, try each, discover HUGE shortcomings, and start again (and again..). Is it just me, or is any decent entry field necessarily descended from TCustomControl? Hey, is TCustomControl even a good place to start? So far, I've some good entry field controls working. They exhibit none of the "why does it do that?" kind of behaviour that inbuilt Windows descendants have. Several have popup-helpers (also descended from TCustomControl) like calendars, numeric keypads etc. Problems to date that I think someone else may have solved are: a) Helper controls show up when some kind of focus rule is imposed, but since they almost always have their parent handle set to 0 ( with Windows.setparent( helper.handle, 0 ) to avoid clipping, they actually appear as a blank button on the taskbar! Does anyone know of an easy way to avoid this? b) Some of the helpers are swallowing keystrokes...they respond to WM_CHAR and WM_KEYUP messages, and set Msg.result appropriately, but other keyboard handlers in the near vicinity ( Form.keypress etc) don't seem to get a look in, AND ITS ONLY SOME KEYS AARGH! c) Double-clicking somewhere in a helper (this is a TCustomControl remember) seems to set some kind of focus flag somewhere, so that if the helper contains other controls, _one_ of them will receive all mouse and keyboard messages, whether or not it is vaguely interested in them. I'm bound to pursue this approach for my entry fields 'coz a, b and c aside, the controls are much better behaved than any of those which re-introduce standard windows behaviour, and are inherently able to operate in a flicker-free fashion. If you've been there and solved some of these problems, I would love to know either i) that you did it (and snicker snicker aren't letting on how) ii) that you did it and here's how, or iii) its impossible, give in and let M$ control the world, iv) that there is a project somewhere wherein Delphi developers can create controls that actually work and I should be contributing, v) that there's actually a good library available out there somewhere (source included) which does this stuff. Here's hoping Trevor --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
