|
I agree, that would be nice to have. I expect MS considers it too complex to sell; the existing stuff is very easy to explain, and they most often seem in favor of dumbing things down... ("You can always clone the collection!")
|
|
|
|
|
To whom would such a contract be 'too hard to sell'? If it would be too difficult to make a collection work nicely, it would be free to throw an exception. Provided that there's a means of determining whether a collection has been changed, I really don't see any advantages to requiring the exception. Further, if Microsoft was willing to disobey the contract on the vb6-style "Collection", why not offer any more useful form of collection that does likewise?
BTW, what would be the proper behavior for a collection which will require a .Dispose call to avoid a memory leak? To implement iEnumerable(of T) as well as iEnumerable, but throw NotImplementedException when a call is made to the non-generic GetEnumerator?
|
|
|
|
|
The way I see it, the programmer needs to be able to predict the behavior, so he can code accordingly. With a more complex behavior a class would risk to be less popular and/or lead to accidents, such as unexpected exceptions (because the user did not understand the contract well).
the vb6-style "Collection" looks like a compromise: what to do to ease VB->VB.NET upgrades while adhering to the .NET conventions? IMO they try to tell us a VB Collection is and is not a collection at the same time.
|
|
|
|
|
The way I see it, the programmer needs to be able to predict the behavior, so he can code accordingly. With a more complex behavior a class would risk to be less popular and/or lead to accidents, such as unexpected exceptions (because the user did not understand the contract well).
I guess I don't really see a whole lot of situations where the exception behavior is more useful than the behavior I described, especially since--if iEnumerator provided a collectionChanged property--one could code a generic class that, given an iEnumerator(of T), would implement iEnumerator(of T) but throw an exception if an effort was made to fetch an item after the underlying class had changed. Thus, if one wanted to have a "For Each" loop that would throw an exception if the collection changed, one could write:
For Each myThing as myClass in New ProtectedEnumerable(myCollection)
...
EndIf
Since one new generic ProtectedEnumerable() class could make any iEnumerable implement the present more-strict contract, I would think the less strict contract would be more useful.
If it were possible to simply implement and use an iNiceEnumerable which followed a different contract, I wouldn't mind the behavior of iEnumerable. As it is, however, iEnumerable and iDisposable are both hard-coded into the compilers for C# and VB.net; if a collection doesn't implement an interface which is called iEnumerable, it can't be used with for-each loop. Even if it would be useful to have an interface defined that implements Microsoft's strict contract, I don't think it's very nice to declare that only interfaces that adhere to that strict contract should be used in for-each loops.
Also, with regard to programmer confusion, it seems far less confusing to say that one must use certain collection types if one is going to modify a collection during enumeration, than to say that one must write enumeration code as:
Using MyNiceEnum as iNiceEnum(of MyThing) = myNiceCollection.GetNiceEnum
Dim MyItem as MyThing
While MyNiceEnum.GetNext
MyItem = MyNiceEnum.TheItem
.. Do something with MyItem
End While
End Using
as opposed to:
For Each MyItem in myNiceCollection
.. Do something with MyItem
Next
|
|
|
|
|
Now think about the implementation details of a protected collection. Most if not all collections are built on top of an array, which gets reallocated and copied every time the capacity becomes insufficient, and which gets insert/remove-shifted on each insertion or removal.
Such collection can have any number of users (methods, possibly active on different threads), each possibly holding one or more enumerators; each enumerator has its own state. Now insert or remove a collection item; how could the collection tell which protected enumerators get affected by the modification, and which don't (because they are already past the insertion/removal point). The natural way would be one of these:
1.
inside the collection, keep a collection of current enumerators and check each of them on every modification, not a pretty situation. (Note: there are life issues, probably needs WeakReferences)
2.
for each enumerator, create a copy of the array, basically cloning the collection. An expensive operation.
The current .NET behavior can easily be accomplished by having a "generation number" which is stored in the collection, incremented on every insert/remove, and gets copied into the enumerator when it gets created, then compared on every Next(). None of these are expensive, memory wise of cycle wise.
|
|
|
|
|
My contract could be just as easily honored. All any of the existing collection classes would have to do honor my 'improved' contract would be to behave exactly as they already do.
My complaint with the Microsoft's iEnumerable contract is that rather than merely requiring an enumerator to throw an exception if the collection has been modified in a way the enumerator can't sensibly handle, it requires that the enumerator throw an exception if the collection is modified, period. That seems unduly harsh.
If someone codes a collection using e.g. a linked list, such that insertions and deletions can be handled without disturbing enumeration (subject to the constraints I listed), is there any reason to forbid its enumerator from operating through insertions and deletions? I know that, from a practical standpoint, Microsoft isn't going to break the kneecaps of any programmer who has the audacity to do such a thing, but it still seems irksome that the best approach would be something Microsoft has declared to be wrong.
|
|
|
|
|
|
I don't think this is new or strange. You obviously can't use upper versions of framework components from lower versions.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Actually I just had a similar experience:
a solution with one 3.5 EXE project referencing two 2.0 DLL projects; it was created long ago with 2008 without any problem (initially it was all 2.0, but then the EXE needed some LINQ and I never got around to modify the DLL targets). When ported to VS2010 I had to modify the DLL projects so they now all target the same framework.
|
|
|
|
|
Yes, but why VS2008 did not make this a problem on compiling?
I agree with you when you say you can't use upper framework form a 2.0 assembly, 'cause, for example it can be deployed on a win2000 or on a machine without .NET 3.0.
But as I say in my previous post, I'll deploy this solution on .NET 3.5 ready machines; only a bug/limit of Cobol<->.NET bridge force me to compile only this Cobol-.NET-interface-assembly in 2.0.
However, I found the trick: reference System.Core.dll (or other dll needed by your referenced assemblies) by hand.
Thanks!
Nando
Jesus
|
|
|
|
|
Hi,
Currently i am using VS 2008 in my PC, now i am planning to install VS 2010 Ultimate in my PC. is its going to effect to my existing applications,if i install this . i want to use my VS 2008 Applications as it is(Don't want to upgrade existing Applications). please suggest me. if it's effects i will roll off from the idea of installing VS2010.
Thanks in advance..
fttyhtrhyfytrytrysetyetytesystryrty
|
|
|
|
|
No problems here so far. It insists on capturing the .sln extensions and wanting to convert them, but that's minor annoyance. Just tell it to eff off.
|
|
|
|
|
You can use both side-by-side.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Public Sub s_zoekEntiteit(ByVal i_entiteit As String)
Dim sqlStr As String = "zoekEntiteit '" & i_entiteit & "'"
Dim dataAdapter = New SqlDataAdapter(sqlStr, m_constring)
Dim commandBuilder As New SqlCommandBuilder(dataAdapter)
Dim DataGridTable As New DataTable()
dataAdapter.Fill(DataGridTable)
Form5.ListBox1.DataSource = DataGridTable
Form5.ListBox1.DisplayMember = i_entiteit
Form5.ListBox1.ValueMember = i_entiteit
End Sub
The Stored Procedure:
CREATE PROCEDURE zoekEntiteit (@tmpEntiteit nvarchar(40))AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
SELECT @tmpEntiteit FROM tblProduct;
--'ByVal i_prodid As String, ByVal i_prodnaam As String, ByVal i_prodomschrijving As String,
--'ByVal i_prodprijs As Int16, ByVal i_prodinstock As String)
END
The RESULT if @tmpEntiteit would be ProdID :
Image to Result
What is wrong here I keep getting an error on ' Form5.ListBox1.ValueMember = i_entiteit' the following error : Can't bind to the new DisplayMember. Paramater newDisplayMember
|
|
|
|
|
I expect its because you don't have a column called i_entiteit in your datatable - your stored procedure returns a column name of (no column name), but as it simply returns the value you pass to it anyway its pointless.
Bob
Ashfield Consultants Ltd
|
|
|
|
|
i am using 3tier design in .net framework,i got two tables called category and menus so i want when i click the button to display in listbox only those who belong in that category..
|
|
|
|
|
And the question is .....?
You haven't provided a question, nor your code, nor any error messages you've gotten, ..., nothing we can use to diagnose your problem.
|
|
|
|
|
Write a query to fetch the appropriate data (those who belong to that category) and then pass it onto the listbox.
|
|
|
|
|
You have not make it clear what how your 3-tier design is related, but concerning your two tables "category" and "menus" you can try INNER JOIN with ON condition which relates the key values in both table.
----------------------------------
Hope it will help you.
|
|
|
|
|
Please provide some detail on your question
so that it is more clearer to answer it.
Jinal Desai
|
|
|
|
|
Hi
can any one help me out in finiding
how to get the mac number of the client system when my application is running in a common server in asp.net
Thanks in advance
Regards,
Gayathri Devi S
|
|
|
|
|
You'll have to seacrh the arp cache. You can find the arp cache in the System.Management; do a query for WIN32_NetworkAdapterConfiguration, and then filter by IP address.
You'll require a full trust environment for this. Note that is NOT the client mac address, but the MAC address of the next hop, if you're connected to a router, or of the bridge if you're connected to a bridge. This will only work in lan environments where clients are connected to switches or hubs.
example here[^]
|
|
|
|
|
Thanks for ur answer
But i need it to view my client mac address
is there anyway to find it using asp.net
|
|
|
|
|
No. It's just not available. The only way to get it is to persuade the client to give it to you.
|
|
|
|
|
No. Information like this is outside the browser security sandbox, and may not be available in the same way because the user could be using a Mac or Linux box. When you think about it, would you really want javascript code (that's what it would have to be), to be able to gain access to client data? This would represent a security hole.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|