VFP6 Grid Behavior Erratic After Adding Phone Field in Front of Date Field in Underlying Record 2

[Booleanist59]

I'm working on a VFP6 app I inherited and I've come across something I can't reconcile.

The grid's record has the usual mix of text, numeric, dates, and a few check boxes in it. I added a field in the underlying table for a phone number (14 char) with no formatting and added it at the end of the grid as the last field. The way the code for a cut and paste menu drop down system works to move appointments around, it replaces the date with the date from the new schedule date when the record gets pasted on a day. This date does not exist in the grid itself of appointments, only in the record in the underlying table for sorting with the time from the option boxes. The problem is the phone number field is coming up with defaulted date delimiters in that cell. I've even recompiled the project to ensure that the new directory move is not affecting this.

This grid is convinced it's a date even though the control sources are all showing the phone field. It displays the schedule's date in the phone field. But when I captured (Cut) the appointment, the _cliptext contents after the cut show the partial phone number but the spacing is off. It's a little odd as the phone number appears in the text string I "cut" when I cut the record from the grid. I suspect there are some extra characters in (spaces) ahead of it (in front of the phone number) and that phone number is getting truncated a few digits off the end of the manually entered phone# from the table's dummy records. How does the date show in the cell but the cut finds the phone number in the record?

I think I might be better off re-writing it long-hand but I figure I'd throw it out there for the VFP community to see if I can learn something from this bizarre behavior.

There are no formatting or input masks in use, all of the max length params for the cells were left at 0. Where the date delimiters " / / " are coming from in the phone field I added onto the grid- I have no idea at this point. When the grid gets to my dummy records, it shows the schedule day's date in the phone cell of the grid. The cut and paste prg's code is included below. Why the truncated phone number is there is a curiousity to tempting to walk away from. Any suggestions or comments would be appreciated.

Thanks for your time,

Dave


**********************************************
* CUT.PRG

if _screen.activeform.caption = "GA/TANF Agency Interviews" or _screen.activeform.caption = "NPA/MED Phone Interviews"

_cliptext = name + casenum + initials + iif(homeless, "1", "0") + address + address1 + city + state + zip + iif(noshow, "1", "0") + ssn + dtoc(dob) + phone

delete
else

* OTHER SCHEDULES​

*!* _cliptext = name + casenum + folder + arrived + source + assigned + called + left + worker + dtoc(completed)
*!* delete
endif

_screen.activeform.refresh
​

return

************************************************************

PASTE.PRG

append blank

do case
case _screen.activeform.caption = "GA/TANF Agency Interviews" or _screen.activeform.caption = "NPA/MED Phone Interviews"
repl name with subs(_cliptext, 1, 40), ;
casenum with subs(_cliptext, 41, 7), ;
initials with subs(_cliptext, 48 ,2), ;
homeless with iif(subs(_cliptext, 50, 1) = "1", .t., .f.), ;
address with subs(_cliptext, 51, 30), ;
address1 with subs(_cliptext, 81, 30), ;
city with subs(_cliptext, 111, 30), ;
state with subs(_cliptext, 141, 2), ;
zip with subs(_cliptext, 143, 10), ;
noshow with iif(subs(_cliptext, 153, 1) = "1", .t., .f.), ;
ssn with subs(_cliptext, 154, 11), ;
dob with ctod(subs(_cliptext, 165, 8)), ;
phone with subs(_cliptext, 173,14) ;
date with m.newDate ;


do case
case _screen.activeform.optiongroup1.value = 1
repl time with "8:45"
case _screen.activeform.optiongroup1.value = 2
repl time with "9:45"
case _screen.activeform.optiongroup1.value = 3
repl time with "10:45"
case _screen.activeform.optiongroup1.value = 4
repl time with "12:45"
case _screen.activeform.optiongroup1.value = 5
repl time with "1:45"
case _screen.activeform.optiongroup1.value = 6
repl time with "2:45"
endcase

case

*case 2 ...​

otherwise
*!* blah blah blah
endcase
​

return


* The 2nd mouse gets the cheese

 

[DSummZZZ]

Did you drill down to Text1 of the grid and take a look at ControlSource and formatting? I know you said there was no grid formatting but it sounds like there may be some for the CurrentControl.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Booleanist59]

Right neighborhood - wrong street. The control source property of that new column was blank - it did not contain the same reference as the text box down below it. I thought I had drilled down every column in that grid checking already - I must have wiped it out somewhere along the way... I know I put it in there when I added it onto the grid. That did get rid of the date formatting for that cell - evidently from the date field immediately before it in the table structure (and the grid). Now I just have to straighten out the substring lengths to get rid of the date encroaching into that field and truncating the phone number.

Thanks for your time and the fresh set of eyes Dave.
(Mine are pretty tired from staying up to watch the Hockey Playoffs the last two weeks.)


* The 2nd mouse gets the cheese

 

[DSummZZZ]

You're welcome. Glad you got it figgered out.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Olaf Doschke]

> The control source property of that new column was blank

That's what I would have adressed first, too. The only reason you see dates or " / / " in a column you expect to have something else is the controlsource. A grid will automatically add a column of the recordsource, if controlsource is empty, you have no unbound columns by default. If the grid is prepared to show a table/view/cursor all you need to set is grid.recordsource and the grid columns are set to display the table columns. All else follows from that behaviour.

Bye, Olaf.

 

[Booleanist59]

Hello Olaf,

There are four of these schedule grids - two had the identical field and columns added but I must have inadvertently erased the control source from the column so it didn't match the text box. What I found so unsettling was the column "retained" the date formatting from the preceding column because of it. I didn't think inheritance (or whatever term you'd apply) would exist horizontally - I always looked at it as a vertical order like parent/child or column/header/textbox. Wasn't sure if it was from inserting the field into the table and recordsets right after the date field, the select statement/filters, or the column's position relative to the preceding column.Switching back and forth between VB and VFP is difficult enough with syntax - statements look correct for one language so they don't always jump out at me when I mix up the commands. (I must be getting too old for this stuff - where did the DOS world go - back when life was simple?)

Thank you both for your input,

Dave


* The 2nd mouse gets the cheese

 

[Olaf Doschke]

Depends on how you add a new column, but in VFP6 you don't have member classes settings, that would add a specific column class, if you higher the column count. Those values are at defaults. I can only assume the table has a date field at the position of the new column and thus the format "mask" was set. Without hands on the form and data it's hard to tell and I am not really keen to find out about eventual VFP6 bugs.

You still can add a textbox to a column in VFP6 or move columns, which may have all kinds of side effects. I am not sure if you move a new column to a position somewhere to the left, the controlsource woudl automatically move to that field or still would show the field corresponding to it's original last rightmost position in the grid and how partially set controlsoruces influence what foxpro displays in a column.

I do know that both the column and the text1 or further controls you put inside a column have a controlsource, and one of them has precedence over the other, so there are at least two places to look and further properties influencing this.

Bye, Olaf.