VFP5.0: Character fields with Null values will not accept text values 
Author Message
 VFP5.0: Character fields with Null values will not accept text values

Hi,
    I have fields with type of C currently holding a null value.  FoxPro
will not permanently accept input on these fields and returns the value
to null after the focus is lost.  This seems to occur somewhere between
the interactivechange event and the valid event.  If I use the de{*filter*}
to set the fields to blank, the input is accepted.  Any suggestions
please!

Jonathan



Tue, 11 Jul 2000 03:00:00 GMT  
 VFP5.0: Character fields with Null values will not accept text values

Hi, Jonathan.  Can you provide more info, please?

-What version of VFP
-What kind of buffering are you using?
-Is this a combo box?
-Do you have the ControlSource set?

--

Nancy Folsom
(abqnfatdamescom--replace the word at and put a dot before the com)



Quote:
> Hi,
>     I have fields with type of C currently holding a null value.  FoxPro
> will not permanently accept input on these fields and returns the value
> to null after the focus is lost.  This seems to occur somewhere between
> the interactivechange event and the valid event.  If I use the de{*filter*}
> to set the fields to blank, the input is accepted.  Any suggestions
> please!

> Jonathan



Tue, 11 Jul 2000 03:00:00 GMT  
 VFP5.0: Character fields with Null values will not accept text values

Nacny,

Version 5.0a  October 21, 1997
This application required WAN access and is using SQL stored procedures to
minimize network traffic.  The actual data item is a form property.  Buffering
should not be applicable.
The field is within an container object proving the look and feel for the
particular data item.  A furhter class provides the look and feel for general
data items and finally a re-defined base class.  (I am new to OOP.  Is this
reasonable?)
This control source is set to thisform.last_name etc.

Jonathan

Quote:

> Hi, Jonathan.  Can you provide more info, please?

> -What version of VFP
> -What kind of buffering are you using?
> -Is this a combo box?
> -Do you have the ControlSource set?

> --

> Nancy Folsom
> (abqnfatdamescom--replace the word at and put a dot before the com)



> > Hi,
> >     I have fields with type of C currently holding a null value.  FoxPro
> > will not permanently accept input on these fields and returns the value
> > to null after the focus is lost.  This seems to occur somewhere between
> > the interactivechange event and the valid event.  If I use the de{*filter*}
> > to set the fields to blank, the input is accepted.  Any suggestions
> > please!

> > Jonathan



Tue, 11 Jul 2000 03:00:00 GMT  
 VFP5.0: Character fields with Null values will not accept text values

Hi, Jonathon.

I don't understand what you mean by "the actual data item is a form
property."  Do you mean the controlSource for the comboBox is setting form
property?  I'm still a bit confused overall.

Could you post the code that would define the combobox you're having
trouble with?

--

Nancy Folsom
(abqnfatdamescom--replace the word at and put a dot before the com)



Quote:
> Nacny,

> Version 5.0a  October 21, 1997
> This application required WAN access and is using SQL stored procedures
to
> minimize network traffic.  The actual data item is a form property.
Buffering
> should not be applicable.
> The field is within an container object proving the look and feel for the
> particular data item.  A furhter class provides the look and feel for
general
> data items and finally a re-defined base class.  (I am new to OOP.  Is
this
> reasonable?)
> This control source is set to thisform.last_name etc.

...snip


Fri, 14 Jul 2000 03:00:00 GMT  
 VFP5.0: Character fields with Null values will not accept text values

Jonathan emailed me the following example.  My response follows.

*Begin Jonathan's message &
example---------------------------------------------------

Hi Nancy,
        Attached is a sample of code that will demonstrate the problem
discussed on microsoft.public.fox.vfp.forms.  When the fields are null
they will not accept new values;  when they are blank new values are
accepted.  This is run against the October 21, 1997 FoxPro 5.0a.

        I am new to OO and FoxPro.  I really do not known if I have
taken sub-classing to an extreme here.  The idea is to sub-class all
base classes for future enhancement and then create a standard look and
feel for a combination label and textbox.

Thanks for paying so much attention to this.  BTW, I did place a "free"
support call to MS on this.  I am waiting for their response.

Jonathan

=============================================================

Information Systems              (250) 370-8607
Capital Health Region
Victoria, BC

FrmClient=CREATEOBJECT("Frm_Client")
FrmClient.Show()
READ EVENTS

* redefine base classes
DEFINE CLASS bcls_page AS page
        Name = "bcls_page"
ENDDEFINE  && bcls_page

DEFINE CLASS bcls_pageframe AS pageframe
        Name = "bcls_pageframe"
ENDDEFINE  && bcls_pageframe

DEFINE CLASS bcls_label AS label
        Height = 17
        Width = 100
        Name = "bcls_label"
ENDDEFINE  && bcls_label

DEFINE CLASS bcls_container AS container
        Name = "bcls_container"
ENDDEFINE  && bcls_container

DEFINE CLASS bcls_form AS form
        Name = "bcls_form"
ENDDEFINE  && bcls_form

DEFINE CLASS bcls_textbox AS textbox
        Height = 23
        Width = 100
        Name = "bcls_textbox"
ENDDEFINE  && bcls_textbox

* create look and feel of a standard label and text item
DEFINE CLASS tcls_labeltext_pair AS bcls_container
        Name = "tcls_labeltext_pair"
        Width = 350
        Height = 23
        BorderWidth = 0

        ADD OBJECT text AS bcls_textbox WITH ;
                Left = 100, ;
                Top = 0, ;
                Width = 250, ;
                Name = "Text"

        ADD OBJECT label AS bcls_label WITH ;
                Top = 3, ;
                Name = "Label"
ENDDEFINE  && tcls_labeltext_pair

* create a specific class for last name
DEFINE CLASS cls_lastname AS tcls_labeltext_pair
        Name = "cls_lastname"
        Label.Caption = "Last Name"
        Text.ControlSource = "thisform.last_name"
        Text.ToolTipText = "Client's Last Name"
ENDDEFINE  && cls_lastname

DEFINE CLASS frm_client AS bcls_form
        Name = "Frm_client"
        Top = -13
        Left = 30
        Height = 560
        Width = 685

        Caption = "Client Information"

    * define our two fields as character
        last_name               = ""
        field2                                  = ""

    * we want a page frame
    ADD OBJECT pageframe1 AS frmclient_pageframe

    add object blank_fields as commandbutton with ;
        label = "BLANKS", ;
        top = 20
    add object null_fields as commandbutton with ;
        label = "NULLS", ;
        top = 40

    procedure blank_fields.click
       thisform.last_name = ""
       thisform.field2 = ""
       =thisform.refresh()
    endproc

    procedure null_fields.click
       thisform.last_name = .null.
       thisform.field2 = .null.
       =thisform.refresh()
    endproc

    * values start off as unknown character fields
    PROCEDURE Init
                thisform.LAST_NAME              = .null.
                thisform.field2                                 = .null.
    ENDPROC

        PROCEDURE Unload
                CLEAR EVENTS
        ENDPROC
ENDDEFINE  && frm_client

DEFINE CLASS frmclient_pageframe as bcls_pageframe
        Name = "frmclient_pageframe"
        Top = 0
        Left = 25
        Width = 565
        Height = 405

        ADD OBJECT demo_page1 AS demo_page
ENDDEFINE

DEFINE CLASS demo_page AS bcls_page
        Name = "Demo_page"
        Caption = "Demographics"
        PageOrder = 1

        ADD OBJECT frmclient_lastname AS cls_lastname WITH ;
                name = 'frmclient_lastname', ;
                Top = 92, ;
                Left = 23

        ADD OBJECT frmclient_field2 AS tcls_labeltext_pair WITH ;
                name = 'frmclient_field2', ;
                Top = 200, ;
                Left = 23, ;
                text.controlsource = 'thisform.field2'
ENDDEFINE

*End Jonathan's message &
example---------------------------------------------------

Thanks for the example, Jonathan, it really helped me understand.  I tried
the code and does work as you say it does.  And that makes sense to me
given the actual situation.  Now, I'm interpreting the behavior, so don't
take it as gospel <g>.  It'll be interesting to hear what MS has to say.

Anyway, your binding textbox controls to  memory variables--not fields.  In
this case the memory vars are custom form properties.  When you set them to
.NULL.  other info you enter is of a different type and is therefore
rejected.  For example, I changed your example to initialize one of the
fields with a number and with a boolean.  When I ran the form I could only
enter numerics in the number field and T or F in the boolean.  I couldn't
"switch" the number to a character.  This is good, because you want to
initialize the field to the type of information you are expecting in it.

When you bind a control to a table field, and the field is .NULL. the field
still has a type (of character, number, etc.), so you can enter a value and
have it "stick."

Take this with a grain of salt, please, because it is definately guessing
on my part.

FWIW, no, I don't think you're going overboard on subclassing.  It looks
reasonable to me.  My only question would be--and this may just be because
you were making up a sample--but why are you binding fields that look like
data entry fields to form properties?  IMO, it's much easier to bind to the
field itself and use table buffering.

Anyway.  Hope everything starts working better!

Regards
--

Nancy Folsom
(abqnfatdamescom--replace the word at and put a dot before the com)



Fri, 14 Jul 2000 03:00:00 GMT  
 VFP5.0: Character fields with Null values will not accept text values

MS has confirmed this as a bug to be fixed in the next release.  Their
suggestion is to either drop the nulls or use memory variables (as oppsoed to
form properties.)

To answer Nancy's question about binding to the database field itself:  this
application is for use over a WAN with slow data lines; to keep data transfer
to a minimum SQL Server stored procedures will be used.  So the use of
buffering is not relevant.  However, if I bind to the SQL cursor it should
work.

Thanks Nancy.  You help is appreciated.

Jonathan

Quote:
> Thanks for the example, Jonathan, it really helped me understand.  I tried
> the code and does work as you say it does.  And that makes sense to me
> given the actual situation.  Now, I'm interpreting the behavior, so don't
> take it as gospel <g>.  It'll be interesting to hear what MS has to say.

> Anyway, your binding textbox controls to  memory variables--not fields.  In
> this case the memory vars are custom form properties.  When you set them to
> .NULL.  other info you enter is of a different type and is therefore
> rejected.  For example, I changed your example to initialize one of the
> fields with a number and with a boolean.  When I ran the form I could only
> enter numerics in the number field and T or F in the boolean.  I couldn't
> "switch" the number to a character.  This is good, because you want to
> initialize the field to the type of information you are expecting in it.

> When you bind a control to a table field, and the field is .NULL. the field
> still has a type (of character, number, etc.), so you can enter a value and
> have it "stick."

> Take this with a grain of salt, please, because it is definately guessing
> on my part.

> FWIW, no, I don't think you're going overboard on subclassing.  It looks
> reasonable to me.  My only question would be--and this may just be because
> you were making up a sample--but why are you binding fields that look like
> data entry fields to form properties?  IMO, it's much easier to bind to the
> field itself and use table buffering.

> Anyway.  Hope everything starts working better!

> Regards
> --

> Nancy Folsom
> (abqnfatdamescom--replace the word at and put a dot before the com)



Fri, 14 Jul 2000 03:00:00 GMT  
 VFP5.0: Character fields with Null values will not accept text values

Thanks for the follow up info from MS, Jonathan.  I know others in similar
situations use SQL cursors and only pull over a subset of the data...
--

Nancy Folsom
(abqnfatdamescom--replace the word at and put a dot before the com)



Quote:
> MS has confirmed this as a bug to be fixed in the next release.  Their
> suggestion is to either drop the nulls or use memory variables (as
oppsoed to
> form properties.)

> To answer Nancy's question about binding to the database field itself:
this
> application is for use over a WAN with slow data lines; to keep data
transfer
> to a minimum SQL Server stored procedures will be used.  So the use of
> buffering is not relevant.  However, if I bind to the SQL cursor it
should
> work.

...snip


Sat, 15 Jul 2000 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Do not accept NULL values

2. Report Field - Concatenating with a field that may be null, nulls whole value

3. Null value in textbox and character to integer

4. NULL values problems in VFP5.0

5. OleDB does not allow to insert NULL Values

6. Replacing null fields with empty values thru ASP

7. null fields and zero values and FP 2.6

8. Null value in a textbox bound to a double table field

9. Numeric field: how to distinguish between no value and 0 value

10. Accepting Alphanumeric Values in a Numeric Grid Control

11. Setting Initial Values in a text field.

12. VFP5.0a, Table Designer, Field Default Value

 

 
Powered by phpBB® Forum Software