BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  TDBEdit and TField EditMask          BorlandTalk.com Forum Index -> C++ Builder (VCL Components Development) View previous topic :: View next topic   Author Message Edward Diener Guest Posted: Fri Nov 07, 2003 1:55 am    Post subject: TDBEdit and TField EditMask I asked this before with no answer, so I will try again. TDBEdit is derived from TCustomMaskEdit so there is an EditMask being applied. The EditMask is not published in TDBEdit so it is not directly manipulatable from the outside. TDBEdit has a Field property which points to the TField which represents the DataField in the database table. I had assumed that the underlying TDBEdit:EditMask would be automatically set to the EditMask of the particular TField. Is this the way TDBEdit is supposed to work ? I derived a component from TDBEdit, set up an application to use that component, with a field in a database table which was of an Integer type, by setting my DataField to the name of that field and my data source to a dataset connected to the appropriate database. I ran the application and looked at the code in the debugger. To my surprise there is no EditMask being set for my TDBEdit derived control. I would have assumed that an Integer field would have set upo an EditMask which only allowed a whole integer value to be input. I tried using other fields with different underlying types but the EditMask was never set. Can anybody explain why the underlying EditMask for my TDBEdit derived class is not working ? Even if I don't use my derived class, but drop a TDBEdit on my form and use it instead, the same result ensues. Back to top Remy Lebeau (TeamB) Guest Posted: Fri Nov 07, 2003 2:26 am    Post subject: Re: TDBEdit and TField EditMask "Edward Diener" <eddielee (AT) tropicsoft (DOT) com> wrote Quote: The EditMask is not published in TDBEdit so it is not directly manipulatable from the outside. With a little extra effort, it is. Quote: I had assumed that the underlying TDBEdit:EditMask would be automatically set to the EditMask of the particular TField. Is this the way TDBEdit is supposed to work ? It is, and does do so. The TDBEdit::EditMask property is updated to the TField::EditMask property whenever the TField data has been changed. Quote: I would have assumed that an Integer field would have set upo an EditMask which only allowed a whole integer value to be input. You assume incorrectly. Keep in mind that there are many different kinds of TField descendant classes used in databasing. EditMask only applies to TStringField. There are completely different classes for numbers - TNumericField, TIntegerField, TFloatField, etc. They use a different property, EditFormat, not EditMask at all. Why it is set up that way, I do not know. Quote: I tried using other fields with different underlying types but the EditMask was never set. Can anybody explain why the underlying EditMask for my TDBEdit derived class is not working ? It is not working because the underlying TField::EditMask property is not used to begin with. It is a user-definable value, the VCL does not set it by default. In fact, the only places that TField::EditMask is actually used is in TStringField::GetText() and TCustomDBGrid.GetEditMask() (for use with the grid's inherited inplace editor). Quote: Even if I don't use my derived class, but drop a TDBEdit on my form and use it instead, the same result ensues. All the more reason to show you that EditMask is not actually used very often. Gambit Back to top Edward Diener Guest Posted: Fri Nov 07, 2003 3:42 am    Post subject: Re: TDBEdit and TField EditMask Remy Lebeau (TeamB) wrote: Quote: "Edward Diener" <eddielee (AT) tropicsoft (DOT) com> wrote in message news:3faafb9e$1 (AT) newsgroups (DOT) borland.com... I would have assumed that an Integer field would have set upo an EditMask which only allowed a whole integer value to be input. You assume incorrectly. Keep in mind that there are many different kinds of TField descendant classes used in databasing. EditMask only applies to TStringField. I am guessing TStringField is used for CHAR and VARCHAR. When would an EditMask for a TStringField be automatically set, or is it the end-user's responsibility to set the corresponding TStringField's EditMask for persistent fields only ? Quote: There are completely different classes for numbers - TNumericField, TIntegerField, TFloatField, etc. They use a different property, EditFormat, not EditMask at all. Why it is set up that way, I do not know. But does EditFormat have anything to do with controlling user input ? In another post on the meaning of EditMask, EditFormat, and DisplayFormat, I was e-mailed directly by some helpful person whose name I have forgotten, and it was suggested to me that EditFormat only controls output display. Quote: I tried using other fields with different underlying types but the EditMask was never set. Can anybody explain why the underlying EditMask for my TDBEdit derived class is not working ? It is not working because the underlying TField::EditMask property is not used to begin with. It is a user-definable value, the VCL does not set it by default. In fact, the only places that TField::EditMask is actually used is in TStringField::GetText() and TCustomDBGrid.GetEditMask() (for use with the grid's inherited inplace editor). When one associates a field with TDBEdit, one just sets up the DataSource and DataField properties. The end-user does not manipulate a field directly unless persistent fields are being used. What you seem to be saying is that for a dynamic field connected to a TDBEdit, no edit masking is done even though TDBEdit is derived from TCustomMaskEdit. Am I correct in all of this ? The doc certainly doesn't explain it as per usual. Quote: Even if I don't use my derived class, but drop a TDBEdit on my form and use it instead, the same result ensues. All the more reason to show you that EditMask is not actually used very often. Well it must be used sometime by TDBEdit, else deriving from TCustomMaskEdit, instead of TCustomEdit, is a waste. If so, when ? Back to top Remy Lebeau (TeamB) Guest Posted: Fri Nov 07, 2003 4:58 am    Post subject: Re: TDBEdit and TField EditMask "Edward Diener" <eddielee (AT) tropicsoft (DOT) com> wrote Quote: I am guessing TStringField is used for CHAR and VARCHAR. It probably depends on the actual database used what VARCHAR would map to. Don't hold me to this, but it might be a TVarBytesField, TMemoField, TBlobField, or TStringField, I think. Quote: When would an EditMask for a TStringField be automatically set It wouldn't be. Quote: or is it the end-user's responsibility to set the corresponding TStringField's EditMask Yes. Well, the TField::EditMask property anyway, since TStringField inherits EditMask. It does not expose it as a new property like TNumericField does with EditFormat. Quote: But does EditFormat have anything to do with controlling user input ? Not really. It is primarily used for display formatting, not input control. On the other hand, EditMask doesn't really control input control either. In fact, looking at TDBEdit's source, it doesn't require the EditMask at all in order to control input. It passes to TField every character that is typed and specifically asks the TField "is this character allowed for you?" and if TField says no (such as typing a letter for a numeric field) the character's keystroke is ignored. Afterwards, when the new value is being assigned to the field after editing, the value will do preliminary validation based on the TCustomMaskEdit::EditMask property value, if one is available. However, the string value is ultimately passed to the TField either way, as a string value via the TField::Text property (which internally invokes the TField::AsString property setter) and then the actual TField decendant that is used for the field is responsible for converting the user's string value into its native data type and to throw an exception if it cannot be converted correctly. Quote: When one associates a field with TDBEdit, one just sets up the DataSource and DataField properties. The end-user does not manipulate a field directly unless persistent fields are being used. If the user makes any changes to the TDBEdit text value, then the TField will be updated, as long as it is in Edit mode. Quote: What you seem to be saying is that for a dynamic field connected to a TDBEdit, no edit masking is done even though TDBEdit is derived from TCustomMaskEdit. Am I correct in all of this ? What I am saying is that masking is not used by default. It is not required in order for the VCL to know how to update field values correctly. However, it is provided as a means of allowing the user to fine-tune the parsing of the inputted text value prior to assignment to the underlying field, if desired. Quote: The doc certainly doesn't explain it as per usual. Which is why I am not referring to the docs for any of this. I'm looking at the actual VCL source code to see what it is really doing. Quote: Well it must be used sometime by TDBEdit Nope. Only if an EditMask is actually specified, which none of the TField classes actually do. Again, it is a user-defined property value, not a VCL defined one. Quote: else deriving from TCustomMaskEdit, instead of TCustomEdit, is a waste. Just because something is provided access to does not mean that it *has* to be used. However, it is provided for cases where it is *desired* to be used. Gambit Back to top JD Guest Posted: Fri Nov 07, 2003 10:35 am    Post subject: Re: TDBEdit and TField EditMask "Edward Diener" <eddielee (AT) tropicsoft (DOT) com> wrote: That didn't take long did it? You just needed to wait for Gambit to get back from vacation!! ~ JD Back to top Edward Diener Guest Posted: Fri Nov 07, 2003 9:52 pm    Post subject: Re: TDBEdit and TField EditMask Remy Lebeau (TeamB) wrote: Quote: "Edward Diener" <eddielee (AT) tropicsoft (DOT) com> wrote in message news:3fab149b (AT) newsgroups (DOT) borland.com... I am guessing TStringField is used for CHAR and VARCHAR. It probably depends on the actual database used what VARCHAR would map to. Don't hold me to this, but it might be a TVarBytesField, TMemoField, TBlobField, or TStringField, I think. OK, but TStringField is the only one of those above that actually use an EditMask according to your last post. Quote: When would an EditMask for a TStringField be automatically set It wouldn't be. or is it the end-user's responsibility to set the corresponding TStringField's EditMask Yes. Well, the TField::EditMask property anyway, since TStringField inherits EditMask. It does not expose it as a new property like TNumericField does with EditFormat. But in TDBEdit the TField property is not published but public instead. This means that the end-user can only set it through code and not through the Object Inspector. Is it really true, therefore, that the only way to use EditMask in TDBEdit is to set its Field -> EditMask through code ? Quote: But does EditFormat have anything to do with controlling user input ? Not really. It is primarily used for display formatting, not input control. On the other hand, EditMask doesn't really control input control either. In fact, looking at TDBEdit's source, it doesn't require the EditMask at all in order to control input. It passes to TField every character that is typed and specifically asks the TField "is this character allowed for you?" and if TField says no (such as typing a letter for a numeric field) the character's keystroke is ignored. This I already knew, but it has nothing to do with EditMask, since EditMask controls characters at specific positions while IsValidChar serves as just a filter. Quote: Afterwards, when the new value is being assigned to the field after editing, the value will do preliminary validation based on the TCustomMaskEdit::EditMask property value, if one is available. The whole point of my post is: how does the underlying TCustomMaskEdit::EditMask of TDBEdit get set ? It isn't directly through the Object Inspector nor through end-user code, since TCustomMaskEdit::EditMask is a protected property. Quote: However, the string value is ultimately passed to the TField either way, as a string value via the TField::Text property (which internally invokes the TField::AsString property setter) and then the actual TField decendant that is used for the field is responsible for converting the user's string value into its native data type and to throw an exception if it cannot be converted correctly. This has nothing to do with EditMask unless TField's EditMask is being applied only after all editing has been done. Quote: When one associates a field with TDBEdit, one just sets up the DataSource and DataField properties. The end-user does not manipulate a field directly unless persistent fields are being used. If the user makes any changes to the TDBEdit text value, then the TField will be updated, as long as it is in Edit mode. This I know of course, but what I meant is that the end-user of TDBEdit can not manipulate its Field property in the Object Inspector. Quote: What you seem to be saying is that for a dynamic field connected to a TDBEdit, no edit masking is done even though TDBEdit is derived from TCustomMaskEdit. Am I correct in all of this ? What I am saying is that masking is not used by default. It is not required in order for the VCL to know how to update field values correctly. However, it is provided as a means of allowing the user to fine-tune the parsing of the inputted text value prior to assignment to the underlying field, if desired. I am confused, so hear are some simple questions: 1) Is TDBEdit::EditMask, derived from TCustomMaskEdit::EditMask, used to control user input for a TDBEdit ? 2) If 1) is yes, how is TDBEdit::EditMask set, considering it is a protected property ? 3) if 1) is no, why is TDBEdit derived from TCustomMaskEdit instead of TEdit ? 4) No matter what 1) is, is TField's EditMask used after editing is done ? 5) If 4) is true, how does on set TField's Editmask ? Back to top Remy Lebeau (TeamB) Guest Posted: Sat Nov 08, 2003 6:12 am    Post subject: Re: TDBEdit and TField EditMask "Edward Diener" <eddielee (AT) tropicsoft (DOT) com> wrote Quote: But in TDBEdit the TField property is not published but public instead. This means that the end-user can only set it through code and not through the Object Inspector. Correct. Unless you write your own TDBEdit descendant and promote the property to published. Quote: Is it really true, therefore, that the only way to use EditMask in TDBEdit is to set its Field -> EditMask through code ? As I already stated, any time the underlying data is changed, the TDBEdit::EditMask property is updated to whatever the TField::EditMask is currently set to. So yes, TField is in control of the masking. Quote: The whole point of my post is: how does the underlying TCustomMaskEdit::EditMask of TDBEdit get set ? I already answered that very question earlier, and again just now. I also stated that EditMask is not used by default at all, so its importance is only in the eyes of the user, not the VCL. Quote: 1) Is TDBEdit::EditMask, derived from TCustomMaskEdit::EditMask, used to control user input for a TDBEdit ? TDBEdit is a descendant of TCustomMaskEdit. It inherits everything that TCustomMaskEdit itself does, just with extra processing ruls on top of it. Quote: 2) If 1) is yes, how is TDBEdit::EditMask set, considering it is a protected property ? I already answered that, but here is a more detailed explanation: TDBEdit has a TFieldDataLink object internally that is attached to the TField. Whenever the TField data is updated, the TFieldDataLink::OnDataChange event is triggered, which TDBEdit has assigned an event handler for. In the handler, the EditMask is updated to the current value of the TField::EditMask property, amongst other things. Quote: 4) No matter what 1) is, is TField's EditMask used after editing is done ? EditMask, as its name suggests, is for *editing*. So no, it is not used *after* editing, only *during*. Gambit Back to top Chris Luck Guest Posted: Sat Nov 08, 2003 7:39 am    Post subject: Re: TDBEdit and TField EditMask "Edward Diener" <eddielee (AT) tropicsoft (DOT) com> wrote Quote: ... why is TDBEdit derived from TCustomMaskEdit instead of TEdit To allow the TDBEdit to properly handle editing when the underlying field has a mask set. Quote: ... how does on set TField's Editmask ? In the ways already provided - not from within any data-aware control. Not happy with that? Let's assume you have created your TMaskDBEdit and drop two instances onto your form. If you set each instance to the same field and give them different masks, which one is going to win? Borland have rightly determined that the mask property should be set in one place only, any other scheme being doomed to failure. -- Regards, Chris Luck Back to top Edward Diener Guest Posted: Sat Nov 08, 2003 8:23 am    Post subject: Re: TDBEdit and TField EditMask Remy Lebeau (TeamB) wrote: Quote: "Edward Diener" <eddielee (AT) tropicsoft (DOT) com> wrote in message news:3fac1405 (AT) newsgroups (DOT) borland.com... 2) If 1) is yes, how is TDBEdit::EditMask set, considering it is a protected property ? I already answered that, but here is a more detailed explanation: TDBEdit has a TFieldDataLink object internally that is attached to the TField. Whenever the TField data is updated, the TFieldDataLink::OnDataChange event is triggered, which TDBEdit has assigned an event handler for. In the handler, the EditMask is updated to the current value of the TField::EditMask property, amongst other things. Thanks. Gambit. I am sure your explanation is correct. So this is my understanding. Essentially to provide a mask for TDBEdit, one needs to manipulate the EditMask for it's underlying TField. For persistent fields this is fine as one can do this in the Object Inspector. For dynamic fields, one must do this at run-time by accessing the underlying TField and changing its EditMask in code. It does still seem odd to me that, given the knowledge of the underlying field type in various database systems, a TField's EditMask isn't automatically set, at least by default, for various field types. But maybe that knowledge is outside the realm of TField derived classes. Still if Borland has specified various TField descendant classes, in its db.hpp field hierarchy, then certainly it knows to associate a derived field type with an actual database column. Back to top Remy Lebeau (TeamB) Guest Posted: Sat Nov 08, 2003 9:55 am    Post subject: Re: TDBEdit and TField EditMask "Edward Diener" <eddielee (AT) tropicsoft (DOT) com> wrote Quote: Essentially to provide a mask for TDBEdit, one needs to manipulate the EditMask for it's underlying TField. Correct. Which, when you think about it, makes sense. That allows the TField to control the editing of any mask-aware DB components that are attached to it. Quote: It does still seem odd to me that, given the knowledge of the underlying field type in various database systems, a TField's EditMask isn't automatically set, at least by default, for various field types. It is not needed, that is why it is not applied by default. I do not know many times I can say that, but I will say it again anyway - EditMask is a ***user-defined*** property value. It is always such, even for non-DB controls. In the case of DB controls, having a mask does *not* effect the actual field itself, only the user display when inputing a new value at a higher level. However, TField can tell mask-aware controls how to work. But a mask is ***not required***, it is optional, only used for fine-tuning the user experience, not any of the actual DB access. That is completely separate. Quote: But maybe that knowledge is outside the realm of TField derived classes. You're missing the point. Quote: Still if Borland has specified various TField descendant classes, in its db.hpp field hierarchy, then certainly it knows to associate a derived field type with an actual database column. The individual DB engines control that initially, but at the same time, such associations are user user-definable via the Object Inspector (well, more accurately, the Fields Editor). Gambit Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> C++ Builder (VCL Components Development) All times are GMT Page 1 of 1   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.