GebhartBob
asked on
Data Addresses vs. Actual Data
I thought I understood this issue pretty clearly, but ran into a situation using VSFlexGrid which made me question how much I really understand.
Please note that this is not a question about VSFlexGrid, but a more general one. You don't have to know dink about VSFlexGrid to help me with this.
VSFlexGrid has a property called "RowData", which is simply a way to associate Variant data with each row of a grid. For example:
fgrGrid.RowData(3) = "abc"
That line will store the string "abc" into a field for Row 3 of "fgrGrid", and can be retrieved later on via:
retrievedData = fgrGrid.RowData(3)
So far, so good. But I got into trouble when I wrote this line:
fgrGrid.RowData(3) = rst!DiskDataField
I thought this was a perfectly clear command, and expected the stored RowData to be whatever was in rst!DiskDataField at the time the command was executed.
Not so. In fact, what I got was the value of rst!DiskDataField at the time the data was **retrieved**. It's as if VSFlexGrid stored the expression "rst!DiskDataField" to RowData, and then evaluated it every time I retrieved it.
Needless to say, that's not what I had in mind. The following fixed the problem, though I consider it a gross kludge:
Dim str As String
str = rst!DiskDataField
fgrGrid.RowData(3) = str
Doing it that way, I always get the value of the recordset field at the time the last statement is executed, not when it's retrieved later on.
Now, this seems very weird to me. I know VSFlexGrid to be a superior grid, so I strongly suspect I'm missing something very important when I feel that the VSFlexGrid handling of RowData is just plain screwed up.
What am I missing?
Please note that this is not a question about VSFlexGrid, but a more general one. You don't have to know dink about VSFlexGrid to help me with this.
VSFlexGrid has a property called "RowData", which is simply a way to associate Variant data with each row of a grid. For example:
fgrGrid.RowData(3) = "abc"
That line will store the string "abc" into a field for Row 3 of "fgrGrid", and can be retrieved later on via:
retrievedData = fgrGrid.RowData(3)
So far, so good. But I got into trouble when I wrote this line:
fgrGrid.RowData(3) = rst!DiskDataField
I thought this was a perfectly clear command, and expected the stored RowData to be whatever was in rst!DiskDataField at the time the command was executed.
Not so. In fact, what I got was the value of rst!DiskDataField at the time the data was **retrieved**. It's as if VSFlexGrid stored the expression "rst!DiskDataField" to RowData, and then evaluated it every time I retrieved it.
Needless to say, that's not what I had in mind. The following fixed the problem, though I consider it a gross kludge:
Dim str As String
str = rst!DiskDataField
fgrGrid.RowData(3) = str
Doing it that way, I always get the value of the recordset field at the time the last statement is executed, not when it's retrieved later on.
Now, this seems very weird to me. I know VSFlexGrid to be a superior grid, so I strongly suspect I'm missing something very important when I feel that the VSFlexGrid handling of RowData is just plain screwed up.
What am I missing?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Ah, I see. I'll play your answer back to you, the way I understood it, just to make sure I've got it 100% straight:
If a procedure specifies a parameter to be a Variant, and one supplies a parameter which can be construed to be an object (rather than its value), then the parameter will be interpreted as an object. The following won't work because it's interpreted as a Field object:
fgrGrid.RowData(2) = rs.fields("DiskDataField")
But any of the following statements will work (I tested them out, just to be sure), because they can't be interpreted as objects:
fgrGrid.RowData(2) = rs.fields("DiskDataField")
fgrGrid.RowData(2) = rs("DiskDataField").Value
fgrGrid.RowData(2) = rs!DiskDataField.Value
Please let me know if I've got that right now.
What you have taught me is that you have to be very careful and very specific when supplying a Variant parameter, because objects are legitimate Variants.
Thank very much for your very lucid answer.
If a procedure specifies a parameter to be a Variant, and one supplies a parameter which can be construed to be an object (rather than its value), then the parameter will be interpreted as an object. The following won't work because it's interpreted as a Field object:
fgrGrid.RowData(2) = rs.fields("DiskDataField")
But any of the following statements will work (I tested them out, just to be sure), because they can't be interpreted as objects:
fgrGrid.RowData(2) = rs.fields("DiskDataField")
fgrGrid.RowData(2) = rs("DiskDataField").Value
fgrGrid.RowData(2) = rs!DiskDataField.Value
Please let me know if I've got that right now.
What you have taught me is that you have to be very careful and very specific when supplying a Variant parameter, because objects are legitimate Variants.
Thank very much for your very lucid answer.
Exactly so.
When you assign to a variant, an object won't use its default property as it would if you assigned it to a string for example. The default property of a Field object is its value, which is why the commonly used syntax rs!abc works most of the time.
Interestingly enough, VB.NET does away with default values (shame, I quite like them), so you _have_ to write sString = rs.fields("abc").value - otherwise you'll get a type mismatch (at compile time if option strict is set).
When you assign to a variant, an object won't use its default property as it would if you assigned it to a string for example. The default property of a Field object is its value, which is why the commonly used syntax rs!abc works most of the time.
Interestingly enough, VB.NET does away with default values (shame, I quite like them), so you _have_ to write sString = rs.fields("abc").value - otherwise you'll get a type mismatch (at compile time if option strict is set).
ASKER
VB.NET doing away with default values is a major-league bummer! Holy Moley, I use defaults all over the place!
Do you mean that something like "txtData = data" will have to be changed to "txtData.text = data"?
Ye gods, that's dumb even for Microsoft!
Do you mean that something like "txtData = data" will have to be changed to "txtData.text = data"?
Ye gods, that's dumb even for Microsoft!
Do NOT use DEFAULT members - they are evil.
It looks like using it can save typing time, but it will make code harder to read, and expand reading time.
Text1 = Text2 ' it is not clear what this means
Text1.Text = Text2.Text ' easy to understand
It looks like using it can save typing time, but it will make code harder to read, and expand reading time.
Text1 = Text2 ' it is not clear what this means
Text1.Text = Text2.Text ' easy to understand
GebhartBob - yep, that's right, you've got to explicitly state text1.text="abc".value (only joking about the .value here).
Actually, I'll go along with ameba's view that defaults are evil. There are a few situations whereby they can be used to fake overloading in VB6, but we get proper overloading in VB.NET anyway. Considering Deplhi's neat editor, sorry, VB's neat editor, there's not that much extra typing, and it spells things out to make code much more readable. If you're used to a language which doesn't have a 'default' concept, text1="Hello" is just plain wiered.
Actually, I'll go along with ameba's view that defaults are evil. There are a few situations whereby they can be used to fake overloading in VB6, but we get proper overloading in VB.NET anyway. Considering Deplhi's neat editor, sorry, VB's neat editor, there's not that much extra typing, and it spells things out to make code much more readable. If you're used to a language which doesn't have a 'default' concept, text1="Hello" is just plain wiered.
ASKER
If defaults are No-no's, then are "With" statements to be avoided as well?
Why are things like this perfectly obvious to everybody but me?
Long drawn-out sigh ....
Why are things like this perfectly obvious to everybody but me?
Long drawn-out sigh ....
ASKER
Concerning ameba's comments---
Do NOT use DEFAULT members - they are evil.
It looks like using it can save typing time, but it will make code harder to read, and expand reading time.
Text1 = Text2 ' it is not clear what this means
Text1.Text = Text2.Text ' easy to understand
Forgive me, but it seems to me that this is very much a matter of personal opinion. If one follows standard naming conventions when assigning names, and consistently uses "txt" to start all TextBox names, then it's perfectly clear (to me, at least) what "txt1 = txt2" means.
Now we're going to have to write this ...
rsFile.Fields("FieldName")
Instead of this ...
rsFile("FieldName") = something
or this ...
rstFile!FieldName = something
I fail to see any advantage in the long-winded approach. To heck with the extra typing effort, though that's a nuisance ... From a readability point of view, I think the short forms are far better.
How can one mistake what rstFile!FieldName means?
But of course I guess in the end it doesn't matter what anybody but Microsoft thinks, a fact which troubles me a great deal.
I don't mean to be argumentative, but this one is going to cost my company a lot of time, to bring old code up to what is to me an an entirely new standard. I don't think the change makes sense, and even if it did, it is a very expensive change.
Maybe somebody has a nice little conversion program, hmmm? My objections would still exist, but would be less strident.
Do NOT use DEFAULT members - they are evil.
It looks like using it can save typing time, but it will make code harder to read, and expand reading time.
Text1 = Text2 ' it is not clear what this means
Text1.Text = Text2.Text ' easy to understand
Forgive me, but it seems to me that this is very much a matter of personal opinion. If one follows standard naming conventions when assigning names, and consistently uses "txt" to start all TextBox names, then it's perfectly clear (to me, at least) what "txt1 = txt2" means.
Now we're going to have to write this ...
rsFile.Fields("FieldName")
Instead of this ...
rsFile("FieldName") = something
or this ...
rstFile!FieldName = something
I fail to see any advantage in the long-winded approach. To heck with the extra typing effort, though that's a nuisance ... From a readability point of view, I think the short forms are far better.
How can one mistake what rstFile!FieldName means?
But of course I guess in the end it doesn't matter what anybody but Microsoft thinks, a fact which troubles me a great deal.
I don't mean to be argumentative, but this one is going to cost my company a lot of time, to bring old code up to what is to me an an entirely new standard. I don't think the change makes sense, and even if it did, it is a very expensive change.
Maybe somebody has a nice little conversion program, hmmm? My objections would still exist, but would be less strident.
With statements are not hiding the subject, they are outlining it.
--
Thanks for taking this seriously, GebhartBob, it is a big compliment for me.
I posted a VB riddle last year, basically it was:
Caption = MsgBox("Hello", 0) ' <<< ERROR
Caption = MsgBox("Hello", 1) ' NO error
and when I asked "HOW IS THIS POSSIBLE" it was nearly impossible to answer it. (I didn't use naming conventions and I used Defaults)
>standard naming conventions when assigning names, and consistently uses "txt" to start all TextBox names
That is great, that helps, but is this enough?
There was a thread on devx news server, vb.oop "Default Property for an object"
----
Karl E. Peterson wrote:
Repeat after me: "Default properties are EVIL!!!"
You will *fully* deserve it when your attitude returns to bite you on the butt.
----
For me, it's all about readability. I read the code of thousands of programmers. I
can tell you, without question, that omitting default properties makes reading alien
code more difficult, if not impossible.
----
I don't agree that "hidden" programming bits contributes to the clarity of the code.
----
default of the picture box is ...geez, what is it...
----
Why? Laziness? Or do you actually feel the cryptic is more readable? (I can accept
laziness, I just wouldn't hire it. <g>)
----
I think VB.NET doesn't allow parameterless default properties, but you will be able to use or create Default member if it accepts arguments, e.g. this will be VALID:
rs(1).Value
rs.Fields(1).Value
or you can use:
col(1) instead of:
col.Items(1)
>it doesn't matter what anybody but Microsoft thinks
Actually, they will now change what was requested by programmers.
---
Tell MS you *demand* an Option Anal, and you want it now!
You don't want anyone -- the compiler, or other programmers -- to "interpret" your code, you
just want them to *read* it with no interpretation necessary.
---
--
Thanks for taking this seriously, GebhartBob, it is a big compliment for me.
I posted a VB riddle last year, basically it was:
Caption = MsgBox("Hello", 0) ' <<< ERROR
Caption = MsgBox("Hello", 1) ' NO error
and when I asked "HOW IS THIS POSSIBLE" it was nearly impossible to answer it. (I didn't use naming conventions and I used Defaults)
>standard naming conventions when assigning names, and consistently uses "txt" to start all TextBox names
That is great, that helps, but is this enough?
There was a thread on devx news server, vb.oop "Default Property for an object"
----
Karl E. Peterson wrote:
Repeat after me: "Default properties are EVIL!!!"
You will *fully* deserve it when your attitude returns to bite you on the butt.
----
For me, it's all about readability. I read the code of thousands of programmers. I
can tell you, without question, that omitting default properties makes reading alien
code more difficult, if not impossible.
----
I don't agree that "hidden" programming bits contributes to the clarity of the code.
----
default of the picture box is ...geez, what is it...
----
Why? Laziness? Or do you actually feel the cryptic is more readable? (I can accept
laziness, I just wouldn't hire it. <g>)
----
I think VB.NET doesn't allow parameterless default properties, but you will be able to use or create Default member if it accepts arguments, e.g. this will be VALID:
rs(1).Value
rs.Fields(1).Value
or you can use:
col(1) instead of:
col.Items(1)
>it doesn't matter what anybody but Microsoft thinks
Actually, they will now change what was requested by programmers.
---
Tell MS you *demand* an Option Anal, and you want it now!
You don't want anyone -- the compiler, or other programmers -- to "interpret" your code, you
just want them to *read* it with no interpretation necessary.
---
You can read "VB Riddle" here: http://www15.brinkster.com/ameba/temp/q10321204.html
EE version, it is NOT sorted OK:
PAQ (15 pts) https://www.experts-exchange.com/jsp/qShow.jsp?qid=10321204
EE version, it is NOT sorted OK:
PAQ (15 pts) https://www.experts-exchange.com/jsp/qShow.jsp?qid=10321204
ASKER
ameba---
I bow to your superior knowledge and experience, though I confess I don't understand. I'm sure I'll come around to your way of thinking sooner or later.
It seems to me that with or without this default properties thing, there is a market for a program which takes VB code, runs it through a wringer, and out the other end comes standardized VB code.
To your knowledge, does any such program exist?
---Bob
I bow to your superior knowledge and experience, though I confess I don't understand. I'm sure I'll come around to your way of thinking sooner or later.
It seems to me that with or without this default properties thing, there is a market for a program which takes VB code, runs it through a wringer, and out the other end comes standardized VB code.
To your knowledge, does any such program exist?
---Bob
Bob,
Yes, there are some programs - VB code analyzer (?) - but last time I checked they only produce warnings, there is no 'correct it automatically'.
>I'm sure I'll come around to your way of thinking sooner or later.
As 'experienced' programmer, I also use little color, no animations (except when user is 'waiting'), and no third party controls.
But, that is not so important, I have seen real ugly code (bad error handling, no comments in source) and the product was successful.
The main thing is to make users happy and sell the product. Right? :)
Yes, there are some programs - VB code analyzer (?) - but last time I checked they only produce warnings, there is no 'correct it automatically'.
>I'm sure I'll come around to your way of thinking sooner or later.
As 'experienced' programmer, I also use little color, no animations (except when user is 'waiting'), and no third party controls.
But, that is not so important, I have seen real ugly code (bad error handling, no comments in source) and the product was successful.
The main thing is to make users happy and sell the product. Right? :)
See also: http://home.component1.com/cmd.boa?product=VSFLX7&cmd=faq&ID=32