|
If I would like to use dictionary , I wouldn't make the question about List.
So your response is off topic.
|
|
|
|
|
No, it's not. Why the hell are you using List<KeyValuePair<>>?
|
|
|
|
|
Because sometimes I need to iterate through the list using the position of each element like this
for I=0 to list1.count-1
...
Next
Can this be used in a dictionary ? ( Exactly like this ??)
|
|
|
|
|
Man you make this difficult. "Just tell me how to do this" without ever explaining why you think you need to do it.
No, a Dictionary<> can't be indexed like that. As you already know, a List<> can. The solution is to make your own List<> class, inheriting from List<KeyValuePair<TKey, TValue>>. You're going to have to implement your own Keys property to expose a Contains for it. Also, you need to expose your own Add methods to add values to the collection. It's really very simple.
Public Class KeyValueList(Of TKey, TValue)
Inherits List(Of KeyValuePair(Of TKey, TValue))
Private _keys As New List(Of TKey)()
Private _values As New List(Of TValue)()
Public ReadOnly Property Keys() As List(Of TKey)
Get
Return _keys
End Get
End Property
Public Overridable Sub Add(key As TKey, value As TValue)
_keys.Add(key)
_values.Add(value)
MyBase.Add(New KeyValuePair(Of TKey, TValue)(key, value))
End Sub
Public Shadows Sub Add(value As KeyValuePair(Of TKey, TValue))
_keys.Add(value.Key)
_values.Add(value.Value)
MyBase.Add(value)
End Sub
End Class
You use this class instead of the List<KeyValuePair<TKey, TValue>> you used. Since it inherits from List<>, it automatically exposes the index property and you get Keys and Values collections that are also indexed and support Contains since they are Lists too.
|
|
|
|
|
Well , I was thinking if a short way exist , because instead of doing your solution , I can just write
List1.Select(Function(t1) t1.key).Contains(MyKey)
But I thought this solution was not the best.
|
|
|
|
|
Define "not the best". That doesn't say anything at all about what's wrong with the approach. I can only guess at what you mean.
So, I go from the standpoint of performance. Every time this line is executed, the code has to build a collection of those keys from scratch and scan each key comparing to the input.
The way I do it, you're maintaining the list of keys constantly. It doesn't have to be built every time. I can also be improved for better lookup performance depending on requirements.
|
|
|
|
|
Using LINQ:
Dim inList As Boolean = YourList.Any(Function(pair) pair.Key = TheKeyToFind)
If you're going to be looking up specific keys, you might be better off using a Dictionary(Of TKey, TValue)[^] instead.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
In a vb.net 2010 desktop application that is using a system.windows.forms.datetimepicker, I am having a problem with. The problem is the datepicker will only allow me to select one month in the past at a time. I hit the down arrow where the date is displayed and then hit the previous button where the month and year are displayed. If I want to go back 3 years in the past, I have to keep this process up 36 times.
I would think I should only have to hit the down arrow where the date is displayed one time, and then keep hitting the back button until I find the month/year I need from 3 years ago. The default selection for the datetimepicker is set today's date since this is what will be used about 95% of the time.
Thus can you tell me what I can do to solve this problem?
|
|
|
|
|
When you see the MonthCalender, displayed by the DateTimePicker, you could move the Cursor over the displayed month and year on the Top.
If you Click the Year now it changes to a NumericUpDown and you could change only the year.
Did you mean something like this ?
modified 18-Jun-15 14:25pm.
|
|
|
|
|
The DateTimePicker will only let you pick a SINGLE point date/time. It will not let you pick a RANGE of dates.
|
|
|
|
|
Hello !
On a Microsoft Word Document , even when a save a document I can undo/Redo step by step all changes that I've made ( until I close the document ).
Is it possible to mimic this behavior on an vb.net application that use a SQL server database ? ( Of course when a record is not yet saved is easily possible to Undo changes , But if is saved ?????) . I'm thinking what is the way that use an application like word to keep in memory changes and easily can move back or forward step by step.
Any idea how can this be realized on a VB.net /SQL server application?
Thank you !
|
|
|
|
|
I'd recommend a memento-pattern; would be a layer higher than the database, and works best if the data is not saved yet.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
MS Word has a comparatively easy job with undo/redo functionality because it's just a single document. Implementing undo/redo for a database application where it should also work for already saved records is a lot more complicated. It gets even more complex if you have data that has to be auditable, like financial transactions. You might want to consider just skipping this feature; after all it can't even remotely be considered standard for database applications. Or maybe implement it in a future release - from what I gather you're developing a new application currently. However..
As the granularity I would choose transactions in order to be able to maintain data integrity.
So you would have to have something like a TransactionID in every entity in order to be able to figure out which entities were created/modified/soft-deleted within the same transaction. Also a history for modified entities (which you already have or plan if I remember correctly). And then if a transaction should be undone, reverse the last action on each entity with that TransactionID. Created ones would be hard-deleted, modified ones their previous values restored from history, soft-deleted ones restored to not deleted.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
It gets worse than that - if you undo your changes, you also have to undo everyone else's changes that have been made since the change you're trying to undo.
For example:
- User A adds a new customer and saves;
- User B adds a new order for the new customer and saves;
- User A now tries to "undo" the new customer;
For user A to "undo" the new customer, they also have to "undo" user B's change.
Also, updates made by other users might not have been allowed without the update made by the first user - think bank accounts, balances and transfers for example.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
This was the first horrifying thought that went through my mind when I read his question. The complexity to implement this and the implications in a multi-user environment sent chills down my spine.
My example was going to be what happens when user A hits undo while user B is saving? User B could (should) get a mysterious concurrency error or User A is going to sit there wondering why the undo didn't undo what they expected and User B is going to wonder where the changes he/she just saved went, because, well, they just got undone.
|
|
|
|
|
Well , from your opinions , seems an "mission impossible".
My idea on a multi-user environment was that if a user try to undo a record , he can return to the last state .
for example :
- User A change the record .vl=5
- User B change the record .vl=8
- User A change the record .vl=20
- User A make a record Undo.
After this undo the record .vl=8
|
|
|
|
|
Depends on the common usage scenario of your application. If, though multi-user is possible, single-user is often the case or updates are not very frequent (e.g. because it's mostly used for querying) then you could consider it. If a user would want to undo a transaction, you would have to halt all uncommitted transactions, ensure that, since selecting "undo", no other transactions have already been committed, undo that transaction and then resume normal operation. If you expect heavy multi-user usage with frequent updates I'd drop the idea.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
That is a single use case.
What happens when you get this:
- User A change the record .vl=5
- User B change the record .vl=8
- User A change the record .vl=20
- User B change the record .vl=25
- User A make a record Undo.
After undo the record .vl=?????
What does the Undo undo? Is it the last change for User A (which is no longer the most current update)? Or is it the last change User B made?
User B's last change may have been milliseconds before User A hits' Undo. So what does User A expect to happen vs. what really does happen?
|
|
|
|
|
In your example , after the UserA undo , the .vl=20.
Always undo the last change.
Anyway let's suppose that the problem that 2 users try to change the same record at the almost same time , doesn't exist.
Now , technically , this Undo/Redo process how can be made ? I mean , an opinion how these "step by step changes " should be saved in order to permit Unod/Redo ?
An idea ?
|
|
|
|
|
satc wrote: Always undo the last change.
By who? From what you just said, the last CHANGES would consist of the last change User A made AND the last change User B made.
satc wrote: Anyway let's suppose that the problem that 2 users try to change the same record at the almost same time , doesn't exist.
Do not EVER make this mistake. Today, that may be the truth, but tomorrow, or next week, or next year, you can't guarantee that.
satc wrote: Now , technically , this Undo/Redo process how can be made ? I mean , an opinion how these "step by step changes " should be saved in order to permit Unod/Redo ?
An idea ?
You didn't change the circumstances under anything anyone hasn't already said. It's possible, but technically difficult and you've got a bunch of cases where unexpected things will happen because multiple people can make changes to the same data at the same time.
|
|
|
|
|
When I say "Undo the Last Change" , I mean " Undo the last change made to the record regardless of who has made the change and who is making the Undo "
At a specific time , A user X can Undo , and the last action that was performed to this record must Undo.
Yes , may be difficult , but as your opinion don't you think that would be a nice feature to have ?
Anyway , if someone has an idea how can be realized , would be a good start to try it.
Thank you !
|
|
|
|
|
You haven't been paying attention to what I've written. The reason you don't see this in applications is because if User B makes a change right before User A hits Undo, and WILL NOT KNOW about the change User B just committed, the undo is not going to undo what User A thought it should.
|
|
|
|
|
You are taking a case that has a low probability to happen.
"In a company 2 users works on the same record without knowing each other actions."
If you take this as probability , well the same problem will happen with the "Save" case.
User A and User B working on the same record trying to change the record with different values and after try to save. User A says to the boss " I change to this" , User B says "I change to this" .. So a chaos. Do you know any company works like this ?
Anyway even in your case the thing has sense.If the user B change right before the user A click Undo , The Undo process will return the state before the changes made by user B. User A can see what the undo has done and can press again undo to move up to another undo level. What's the problem here ? and just like in Word where you can see what actions you are Undo , here we can include in the Undo comments who has done the action that we are just trying to undo.
The idea of "Step by Step" Undo/Redo is to help people to return /forward to another step if they think that a mistake is done , just like in the Word where something that we have doesn't like to us we can go back step by step.
Instead of loosing time to this discussion , have someone an idea how can this be realized ?
Thank you !
|
|
|
|
|
satc wrote: You are taking a case that has a low probability to happen.
HA HA HA HA HA !!! You haven't been doing this for very long, have you? It WILL bite you in the ass! The second you say it's "rare" for that to happen, it'll happen within 10 minutes of you deploying your code to production.
Also, "rare" is not "cannot ever happen". It WILL happen and you WILL lose data when it does.
In my example, it doesn't have to be two people updating the same record within milliseconds of each other. Both users can retrieve the data, User B can update the record while User A stares at the ceiling tiles for 20 minutes before he decides to undo his last change. Guess what just happened! User A didn't retrieve the record again and didn't know that User B made a change!
How are you going to handle that? You WILL have to handle that situation.
satc wrote: Do you know any company works like this ?
Yes! The problem is called "concurrency" and people who write code have to deal with it every single day. Read up on it here[^]. There are various modes in which collisions like this can occur and various solutions to the problem, each with their pros and cons. Your job is to map your business rules to the situation and choose an appropriate method to deal with the problem, given the down side to the chosen solution.
In the website that I'm working on right now, we use two rules depending on the situation. We use either "last write wins" for data that isn't sensitive to changes of state and "optimistic concurrency" with the stuff that must maintain a consistent state across all involved fields. The later rule covering about 90% of our data.
satc wrote: just like in the Word
You absolutely can NOT compare Word to a multi-user database scenario. The problems are very different, with document editing being very easy to back out. The reason for this is because the code maintains the state of the data (Word document) completely on its own WITHOUT ANY OUTSIDE ALTERATIONS to the data being possible because only one person can edit the document at a time.
Any data in a database can be changed by anyone at any time. Your code on one workstation will not know a change was made by another workstation.
Database changes cannot be backed out so easily without very careful consideration of the different possibilities where changes are being made and accounting for every single one of them in your code. You immediately failed at this requirement the second you dismissed even one possibility as a "rare" occurrence.
Make no mistake. What you want to do is not simple. In fact, it's quite a large project in itself and many things to consider and design for, even the stuff that has only, say, a 1 millisecond window of opportunity to happen.
satc wrote: Instead of loosing time to this discussion , have someone an idea how can this be realized ?
You've already been told what you have to do and the possible pitfalls of various methods. The discussion of what you have to account for in your design and how to account for various things (given your business rules) will be a VERY long conversation and one that I doubt anyone is willing to take on in a forum environment.
|
|
|
|
|
When I say " Has a low probability to happen" ,I mean in the environment that I intend to apply it. I'm not talking in general. You don't know nothing about this , so take as TRUE that I'm saying.
Taking this supposition , can you give me an idea how to implement it or no ?
So can this be done or no , If no , ok end of the conversation.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
