Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
anyone knows where is overview of knows VFP bugs?
- Thread starter Nifrabar
- Start date
Olaf Doschke
Programmer
From the top of my head:
[URL unfurl="true"]http://fox.wikis.com/wc.dll?Wiki~VFP9SP2BugList[/url]
It's pretty empty and the feedback of bugs of course is not available anymore.
You won't find a list of bugs, each sp only has a list of fixes.
I wonder, if what you're seeing really is a bug. When you backspace in one control you go back to another control in tab order and there would eventually be code changing record position.
Also it's not a bug, that a form and it's controls do not refresh on theiur own, when you change the record. If you "suddenly" see data from previous records thats perhaps because you "suddenly" activate a control and it refreshes at that moment. There's any easy repro: HAve several textboxes bound to a field, show a record, then SKIP 1 without a form.refresh(), then click inside the single textboxes and you see the values of the next record.
The same applies to yet unbuffered data, in the moment you click into a textbox VFP retreives the curval, unless the field already had changed and you see the buffered change already. That means:
If you bind to a record and even if you stay there, and have record or table buffering on and another user or you changes that record shown and save in another session or another form instance, when you click on this form, you will see that change. Because only when you begin editing a record, your change will overlay what's in the DBF.
In short: seeing new or old or current values when you change to a control or reactivate a form can be very normal and by design. There's nothing spooky going on. One topic and setting to look for is SET REFRESH, which determines what VFP does on it's own. If you set this to special values 0 or -1 you may see behaviour you're not used to, becuase you are used to the opposite or to the third behaviour by setting it to a positive amount of seconds.
Bye, Olaf.
[URL unfurl="true"]http://fox.wikis.com/wc.dll?Wiki~VFP9SP2BugList[/url]
It's pretty empty and the feedback of bugs of course is not available anymore.
You won't find a list of bugs, each sp only has a list of fixes.
I wonder, if what you're seeing really is a bug. When you backspace in one control you go back to another control in tab order and there would eventually be code changing record position.
Also it's not a bug, that a form and it's controls do not refresh on theiur own, when you change the record. If you "suddenly" see data from previous records thats perhaps because you "suddenly" activate a control and it refreshes at that moment. There's any easy repro: HAve several textboxes bound to a field, show a record, then SKIP 1 without a form.refresh(), then click inside the single textboxes and you see the values of the next record.
The same applies to yet unbuffered data, in the moment you click into a textbox VFP retreives the curval, unless the field already had changed and you see the buffered change already. That means:
If you bind to a record and even if you stay there, and have record or table buffering on and another user or you changes that record shown and save in another session or another form instance, when you click on this form, you will see that change. Because only when you begin editing a record, your change will overlay what's in the DBF.
In short: seeing new or old or current values when you change to a control or reactivate a form can be very normal and by design. There's nothing spooky going on. One topic and setting to look for is SET REFRESH, which determines what VFP does on it's own. If you set this to special values 0 or -1 you may see behaviour you're not used to, becuase you are used to the opposite or to the third behaviour by setting it to a positive amount of seconds.
Bye, Olaf.
Mike Lewis
Programmer
Bart,
Microsoft publishes list of known bugs for each major release and service pack of VFP. You can find them by entering this term in Google:
However, the lists don't contain any bugs that developers have discovered but which Microsoft has not yet acknowledged or fixed. It's likely that they don't cover the most recent bugs.
The link that Olaf gave you is a good source - mainly because the list is maintained by developers rather than by Microsoft. But keep in mind that it might be quite out of date, as it has not been updated since January 2010.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
Microsoft publishes list of known bugs for each major release and service pack of VFP. You can find them by entering this term in Google:
Code:
site:support.microsoft.com visual foxpro bugsHowever, the lists don't contain any bugs that developers have discovered but which Microsoft has not yet acknowledged or fixed. It's likely that they don't cover the most recent bugs.
The link that Olaf gave you is a good source - mainly because the list is maintained by developers rather than by Microsoft. But keep in mind that it might be quite out of date, as it has not been updated since January 2010.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
- Thread starter
- #4
Olaf, thanks for link,
Still thinking it's a bug. As I thought it might be caused by my subclassed textbox-class I put a base-class textbox on my form with same result as down below.
Scenario:
Form with in dataenvironment a buffered view as controlsource.
Two textboxes A and B with same controlsource.
A with format property set to (character) T.
B with default format (= none)
A: place cursor at pos 0. press DEL (not tab) several times. Once all data is gone data of former record (which was viewed in same session) appears. (as long as that value consists of more characters than the current record being 'delled' away)
B: same action but without seeing same behaviour, just as expected only data disappearing as result of DEL key.
Loved to use the T value for format tp prevent leading spaces but not usable.
Any idea?
Mike,
Not much luck by googling this.
-Bart
Still thinking it's a bug. As I thought it might be caused by my subclassed textbox-class I put a base-class textbox on my form with same result as down below.
Scenario:
Form with in dataenvironment a buffered view as controlsource.
Two textboxes A and B with same controlsource.
A with format property set to (character) T.
B with default format (= none)
A: place cursor at pos 0. press DEL (not tab) several times. Once all data is gone data of former record (which was viewed in same session) appears. (as long as that value consists of more characters than the current record being 'delled' away)
B: same action but without seeing same behaviour, just as expected only data disappearing as result of DEL key.
Loved to use the T value for format tp prevent leading spaces but not usable.
Any idea?
Mike,
Not much luck by googling this.
-Bart
Olaf Doschke
Programmer
Sorry, I can't reproduce this. No matter how often I hit DEL, the textbox simply stays empty, nothing else happens.
Can you upload a sample somewhere including form, data and view? I'll take a look at it. I don't remember any bug report about DEL, I just have a fainted memory of someone having a problem with backtabbing to a previous control by DEL within an empty textbox, that's why I mentioned it. It doesn't help, if you only exchange that textbox, it might be another control or the forms keypreview or a defined key macro. There are still many more things in question than inherited class code.
Bye, Olaf.
Can you upload a sample somewhere including form, data and view? I'll take a look at it. I don't remember any bug report about DEL, I just have a fainted memory of someone having a problem with backtabbing to a previous control by DEL within an empty textbox, that's why I mentioned it. It doesn't help, if you only exchange that textbox, it might be another control or the forms keypreview or a defined key macro. There are still many more things in question than inherited class code.
Bye, Olaf.
- Thread starter
- #6
Dan Freeman
Programmer
Hmmmm... not sure what you're expecting from FORMAT = "T" in a bound control.
The help file says "Trims leading and trailing blanks from the input field." If the control is bound to a fixed-length field in a table, it can't possibly trim trailing blanks -- they're part of the data. At that point you're asking the property to do something it cannot do, which is a recipe for unpredictable behavior.
The help file says "Trims leading and trailing blanks from the input field." If the control is bound to a fixed-length field in a table, it can't possibly trim trailing blanks -- they're part of the data. At that point you're asking the property to do something it cannot do, which is a recipe for unpredictable behavior.
- Thread starter
- #8
Olaf Doschke
Programmer
Unpredictable behavior doesn't guarantuee errors. In fact in general, even if it's not about a flaw in VFP but in own code (and I talk generally here, also of my applications), the easy part os to fix errors, which cause error masseges. The hard part is to find the sources leading to false results, and sometimes even users, who use the software on a daily basis are blind to them and only discover something wrong at a totally different place, giving you a false idea, of where the error could be.
In this case, your erroneous behavior is happening very local. If it's really just the textbox bound to a buffered view and he format "T" causing that behaviour, I would have reproduced, because I did put all that together and test. But for me what you saw didn't happen. In my case the empty textbox stayed empty, there has to be something else in play.
Try to start from scratch in an empty form and upload a sample project to a website, I'm willing to examine it. You already know a workaround in not using that Format, but I'm saying it's not the only reason. It's fine if you fix it by doing an ALLTRIM on the data before TABLEUPDATE, but it would give a better feeling, if you would know what exactly is causing this, wouldn't it?
Bye, Olaf.
In this case, your erroneous behavior is happening very local. If it's really just the textbox bound to a buffered view and he format "T" causing that behaviour, I would have reproduced, because I did put all that together and test. But for me what you saw didn't happen. In my case the empty textbox stayed empty, there has to be something else in play.
Try to start from scratch in an empty form and upload a sample project to a website, I'm willing to examine it. You already know a workaround in not using that Format, but I'm saying it's not the only reason. It's fine if you fix it by doing an ALLTRIM on the data before TABLEUPDATE, but it would give a better feeling, if you would know what exactly is causing this, wouldn't it?
Bye, Olaf.
Dan Freeman
Programmer
Then you need to adjust your expectations to match reality rather than something you've made up.
As Olaf says you need to start with the simplest case and build up to the full scenario, carefully testing at each step to determine exactly what is causing what you're seeing. It's often something you'd never think to question but you'll only know it when you're testing that one thing and only that one thing.
- Thread starter
- #11
Olaf, Dan,
Thanks for yr advice.
As both of you don't think this is a real bug than it must be have to do with my code.
The pity is that the dataform it concerns is for me quite complex so this requires just enough time to trace matters.
I will come back with my results but due to the fact that there is a workable workaround it will get a lower priority.
Anyway thanks for sharing again yr knowledge.
-Bart
Thanks for yr advice.
As both of you don't think this is a real bug than it must be have to do with my code.
The pity is that the dataform it concerns is for me quite complex so this requires just enough time to trace matters.
I will come back with my results but due to the fact that there is a workable workaround it will get a lower priority.
Anyway thanks for sharing again yr knowledge.
-Bart
Olaf Doschke
Programmer
I understand the lower priority. What I would suggest, though, is that you start a new separate form and put in what you think is causing the error, the textbox and the view. Indeed the view itself could influence this behavior in some way and we don't have your data nor your view definition. And it's not yet clear, you have introduced the bug with your code, it could depend on several settings we don't have made, you know there are in the range of 10-20 settings influencing VFP behavior in regard of buffering, refreshing, etc.
It's not at all clear, what will be the finding, it's just clear your observation isn't wrong, I also don't doubt not using format to "T" you observe no error, and I understand you conclude this is the fault, but I can also setup a textbox bound to a buffered view and I don't share your observation. So you're not wrong, but you're also not right, there has to be something else in play, there must be something else having influence. It doesn't need to be your data, but it could be, it doesn't have to be your view definition, but it could be, it doesn't have to be settings like REFRESH, but it could be. We don't know yet, but there's no doubt it's just the format setting. I can totally understand, how you come to your conclusion, but it can be easily tested by anybody, that those few prerequisites of the format and the buffered view are not enough to reproduce that bug, so one last time: There must be something else in play.
OK?
I don't blame you and I don't doubt what you observe, there's nothing personal in here. But just taking your report and putting up everything I can't reproduce your observation.
Bye, Olaf
It's not at all clear, what will be the finding, it's just clear your observation isn't wrong, I also don't doubt not using format to "T" you observe no error, and I understand you conclude this is the fault, but I can also setup a textbox bound to a buffered view and I don't share your observation. So you're not wrong, but you're also not right, there has to be something else in play, there must be something else having influence. It doesn't need to be your data, but it could be, it doesn't have to be your view definition, but it could be, it doesn't have to be settings like REFRESH, but it could be. We don't know yet, but there's no doubt it's just the format setting. I can totally understand, how you come to your conclusion, but it can be easily tested by anybody, that those few prerequisites of the format and the buffered view are not enough to reproduce that bug, so one last time: There must be something else in play.
OK?
I don't blame you and I don't doubt what you observe, there's nothing personal in here. But just taking your report and putting up everything I can't reproduce your observation.
Bye, Olaf
- Thread starter
- #13
Hi Olaf!
Im my textbox-subclass I use to have in the init a piece of code borrowed from the book 1001 things you wanted to know about visual foxpro written by Marcia Akins, Andy Kramek and Rick Schummer.Th ebook is based on VFP6 meanwhile we are running now VFP9 with sp2.
After 'flagging-off' this piece of code my 'error' is gone.
Do you see in this code something that might cause the error?
Im my textbox-subclass I use to have in the init a piece of code borrowed from the book 1001 things you wanted to know about visual foxpro written by Marcia Akins, Andy Kramek and Rick Schummer.Th ebook is based on VFP6 meanwhile we are running now VFP9 with sp2.
After 'flagging-off' this piece of code my 'error' is gone.
Do you see in this code something that might cause the error?
Code:
* setinputmask
LOCAL lcAlias, lcField, lcType, laFields[1], ;
lnElement, lnRow, lcIntegerPart, lcDecimalPart
WITH This
IF ! EMPTY( .ControlSource )
IF EMPTY( .InputMask )
*** Only set the inputmask for numeric and character fields
*** and check the data type of the underlying field so we
*** can set it appropriately
lcType = TYPE( This.ControlSource )
IF INLIST( lcType, 'C', 'N' )
*** Parse the alias and the field name from the ControlSource
lcAlias = JUSTSTEM( .ControlSource )
lcField = JUSTEXT ( .ControlSource )
*** Don't attempt to check the properties of the underlying
*** field if we are bound to a form property
IF UPPER( lcAlias ) # 'THISFORM'
*** format the field if it is character
IF lcType = 'C'
.InputMask = REPLICATE( 'X', FSIZE( lcField, lcAlias ) )
ELSE
AFIELDS(laFields, lcAlias)
lnElement = ASCAN(laFields, UPPER(lcField))
IF lnElement > 0
lnRow = ASUBSCRIPT(laFields, lnElement, 1)
lcIntegerPart = REPLICATE('9', laFields[lnRow, 3] - laFields[lnRow, 4] - 1)
lcDecimalPart = REPLICATE('9', laFields[lnRow, 4])
.InputMask = lcIntegerPart + '.' + lcDecimalPart
ENDIF
ENDIF
ENDIF
ENDIF
ENDIF
ENDIF
ENDWITHOlaf Doschke
Programmer
No, and it doesn't help to go into such details.
Start from a new form with a native textbox and see for yourself, if you can reproduce the behavior you see. If not, then you can add further things you use in your problematic form. Only you can do this experimenting and testing. It doesn't help at all, if you bring pieces here, you have to find out, please.
My current suspicion is setting, not code, SET REFRESH, any other setting. And then ON KEY LABEL, and then perhaps some class code. But you already said you tried to comment out any class code or used a native textbox and also saw the same behaviour, didn't you say that?
Only you have your vfp setting with your foxuser.dbf and your registry settings. Again, I can not reproduce your problem, find a minimum form with textbox, with view, data and settings, that reproduces the behavior on it's own and then I will have a look into it. But I'll not do wild guesses an what could cause this.
You're still not getting how you should systematically add things, starting from scratch, until you get the behavior. If you get the behavior already with the native textbox, it can't be "1001 things code", can it be? So why are you searching along this? Do you listen to me at all?
Bye, Olaf.
Start from a new form with a native textbox and see for yourself, if you can reproduce the behavior you see. If not, then you can add further things you use in your problematic form. Only you can do this experimenting and testing. It doesn't help at all, if you bring pieces here, you have to find out, please.
My current suspicion is setting, not code, SET REFRESH, any other setting. And then ON KEY LABEL, and then perhaps some class code. But you already said you tried to comment out any class code or used a native textbox and also saw the same behaviour, didn't you say that?
Only you have your vfp setting with your foxuser.dbf and your registry settings. Again, I can not reproduce your problem, find a minimum form with textbox, with view, data and settings, that reproduces the behavior on it's own and then I will have a look into it. But I'll not do wild guesses an what could cause this.
You're still not getting how you should systematically add things, starting from scratch, until you get the behavior. If you get the behavior already with the native textbox, it can't be "1001 things code", can it be? So why are you searching along this? Do you listen to me at all?
Bye, Olaf.
- Thread starter
- #15
Hi Olaf,
Test scenario:
Native form.
Native textbox(1) with just in the init the code for 'setinputmask'.
Native textbox(2) nothing in the init.
Both textboxes with format property set to T
Two buttons to skip and skipback (include refresh)
Controlsource is optimistic table buffered view. (5)
Scroll through view using skip button
Data displayed consisting of e.g. 10 digits.
Next records displays content of e.g. 5 digits (must be less than former 10).
Place cursor at pos.0
press del 5 times >>data is gone
resume pressing del key >>surprise ! part of 10 digits is there.
So the setinputmask seems to cause the behaviour when Format = T
I also tried with no buffered table i.s.o. buffered view with same result.
What's your opinion on this?
-Bart
Test scenario:
Native form.
Native textbox(1) with just in the init the code for 'setinputmask'.
Native textbox(2) nothing in the init.
Both textboxes with format property set to T
Two buttons to skip and skipback (include refresh)
Controlsource is optimistic table buffered view. (5)
Scroll through view using skip button
Data displayed consisting of e.g. 10 digits.
Next records displays content of e.g. 5 digits (must be less than former 10).
Place cursor at pos.0
press del 5 times >>data is gone
resume pressing del key >>surprise ! part of 10 digits is there.
So the setinputmask seems to cause the behaviour when Format = T
I also tried with no buffered table i.s.o. buffered view with same result.
What's your opinion on this?
-Bart
Olaf Doschke
Programmer
Hi Bart,
first of all, thanks for taking the time. I'll try that. In the meantime I already tried a form with 2 controls to verify DEL really causes to back tab into a previous control. It does, and so many events occcur, that can cause many things: valid and lostfocus of the textbox left with DEL, when and gotfocus of the textbox getting control.
Now I'll try what you propose, one more question (I'll simply try both) The numeric value with 10 vs less digits, should that be in a char field? or a numeric field? The field type may play a role.
Your code "setinputmask" mainly does one thing, it sets the inputmask property to a number of X in the length of the field, this contradicts the T format, the field will have a fixed length also without the inputmask, but that mask may cause this in conjunction with trimming.
We'll see. I'll come back later.
Bye, Olaf.
first of all, thanks for taking the time. I'll try that. In the meantime I already tried a form with 2 controls to verify DEL really causes to back tab into a previous control. It does, and so many events occcur, that can cause many things: valid and lostfocus of the textbox left with DEL, when and gotfocus of the textbox getting control.
Now I'll try what you propose, one more question (I'll simply try both) The numeric value with 10 vs less digits, should that be in a char field? or a numeric field? The field type may play a role.
Your code "setinputmask" mainly does one thing, it sets the inputmask property to a number of X in the length of the field, this contradicts the T format, the field will have a fixed length also without the inputmask, but that mask may cause this in conjunction with trimming.
We'll see. I'll come back later.
Bye, Olaf.
- Thread starter
- #17
Olaf Doschke
Programmer
OK, I can reproduce the behavior now. Now I'll play a bit with all the settings.
One thing is for sure, already: It's a mystery how VFP grabs a value from the next or previous record, because if you put a browse window side by side to the form, there is no movement in the view, record pointer stays on the current record. VFP grabs something it has kept in memory from the record viewed before.
Really strange. Really, really strange.
I'd suggest additional to removing the T from the format you put this into the valid event:
Or don't set Inputmask. It's just the combination of a XXXXXXX inputmask and format T causing this.
I'll keep trying with other data sources and buffer modes.
Bye, Olaf.
One thing is for sure, already: It's a mystery how VFP grabs a value from the next or previous record, because if you put a browse window side by side to the form, there is no movement in the view, record pointer stays on the current record. VFP grabs something it has kept in memory from the record viewed before.
Really strange. Really, really strange.
I'd suggest additional to removing the T from the format you put this into the valid event:
Code:
This.Value = Alltrim(This.Value)
Return dodefault()Or don't set Inputmask. It's just the combination of a XXXXXXX inputmask and format T causing this.
I'll keep trying with other data sources and buffer modes.
Bye, Olaf.
- Thread starter
- #19
Olaf, For that I originally presumed it's a VFP-bug.
Regarding yr suggestion I put that in my custom lostfocus method. But I presume that due to the 'reset of fldstate' requery fails (uncommitted changes).
But I will give it a try in the valid method.
I know you don't like my solution for resetting the fldstate but my users complained for the message : do you want to save the changes. They caused a change by editting a field and afterwards changed back to the original value [curval()].
-Bart
Regarding yr suggestion I put that in my custom lostfocus method. But I presume that due to the 'reset of fldstate' requery fails (uncommitted changes).
But I will give it a try in the valid method.
I know you don't like my solution for resetting the fldstate but my users complained for the message : do you want to save the changes. They caused a change by editting a field and afterwards changed back to the original value [curval()].
-Bart
Code:
* _ObjectProperties
LPARAMETERS tForm, tObject
LOCAL lcAlias, lcType, lnBufferMode, lnFieldState, lNewRecord, luOldValue,i
lcAlias = ""
lcType = ""
lnBufferMode = 0
lnFieldState = 0
lNeRewcord = .F.
WITH tObject
IF VARTYPE(tForm)="O"
IF PEMSTATUS(tForm,'lNewRecord',5)
lNewRecord = tForm.lNewRecord
ENDIF
ENDIF
IF !EMPTY(.ControlSource) AND ! 'THISFORM' $ UPPER(.ControlSource)
** remove leading spaces
IF TYPE( .ControlSource )=="C"
*Undermentioned code is disabled; although fldstate will be reset this causes requery of teh view to fail
* .Value = ALLTRIM(.Value)
ENDIF
IF '.' $(.ControlSource)
lcAlias = JUSTSTEM(.ControlSource)
ENDIF
lcFieldName = JUSTEXT(.ControlSource)
IF !EMPTY(lcAlias)
lnSelect = SELECT()
SELECT (lcAlias)
lnBuffermode = CURSORGETPROP("Buffering")
IF lnBuffermode > 1
lnFieldState = GETFLDSTATE(lcFieldName,lcAlias)
luOldValue = CURVAL(lcFieldName, lcAlias)
ENDIF
SELECT (lnSelect)
ELSE
lnBuffermode = CURSORGETPROP("Buffering",lcAlias)
lnFieldState = GETFLDSTATE(lcFieldName)
luOldValue = CURVAL(lcFieldName)
ENDIF
ENDIF
DO CASE
CASE lnBufferMode > 1 AND !lNewRecord AND !EMPTY(lcAlias) AND (ALLTRIM(TRANSFORM(luOldValue)) == ALLTRIM(TRANSFORM(.Value))) AND (lnFieldstate = 2 OR lnFieldstate = 4)
SETFLDSTATE(lcFieldName,ICASE(lnFieldState=4,3,lnFieldState=2,1),lcAlias)
CASE lnBufferMode > 1 AND !lNewRecord AND EMPTY(lcAlias) AND (ALLTRIM(TRANSFORM(luOldValue)) == ALLTRIM(TRANSFORM(.Value))) AND (lnFieldstate = 2 OR lnFieldstate = 4)
SETFLDSTATE(lcFieldName,ICASE(lnFieldState=4,3,lnFieldState=2,1))
ENDCASE
ENDIF
ENDWITH
RETURN
*!* 1 Field has not been modified or deletion status has not change
*!* 2 Field has been modified or deletion status has changed.
*!* 3 Field in an appended record has not been modified or deletion status has not changed for the appended record.
*!* 4 Field in an appended record has been modified or deletion status has changed for the appended record.- Status
Similar threads
- Question