|
Hmmm... I never knew it was even there. I've never had a reason to use anything like it.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
how can i use the 'or' function. I want that if the user didn't enter a specific username ex: liba or demel or pufta! how can i do this?? i am using this but it aint working:
If text = "pufta" Or "demel" Then
MessageBox.Show("You have registered for the program. Now close the registration menu and start using the program. Have Fun!!", _
"Registration Completed", MessageBoxButtons.OK, MessageBoxIcon.Information)
s.WriteLine(txtbox.Text)
s.Close()
End If
Adrian
|
|
|
|
|
Or doesn't work like that. Below is how or works.
if text = "pufta" or text = "demel" then
'do stuff
end if
if case doesn't matter (D and d are the same), I would use the following:
if string.compare(text, "pufta", true) = 0 _
or string.compare(text, "demel", true) = 0 then
'do stuff
end if
|
|
|
|
|
If textbox1.text = "pufta" Or "demel" Then
MessageBox.Show("You have registered for the program. Now close the registration menu and start using the program. Have Fun!!", _
"Registration Completed", MessageBoxButtons.OK, MessageBoxIcon.Information)
s.WriteLine(txtbox.Text)
s.Close()
End If
I think you were missing the bold part....
|
|
|
|
|
|
Mr. Dave.. the client ll be having the VB.NET interface from which he ll be accessing the contents (audio, video, text, PDFs etc) located on the server...
as i told u before only, not having much idea abt VB.net and MSSQL Server...
so i would like to know whether the transaction as i told above ll be possible or not ?? as we ll be using Windows Media Player, Microsoft Word and the respective components for the desired contents...
and once again..thanks for ur ideas n info
|
|
|
|
|
It's possible. Your VB.NET app would have to get the path to the file from your SQL database, get the path for the root of your media storage files, combine the two paths together to form a complete path to the file on the server, then just launch it. Simple...
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
hello, i am using the stream reader and writer to write on a textfile. When i am sending this program to my friend he is gaining problems. because the root of the textfile is different from mines. how can i make it to make the textfile somewhere good for everybody to work the program well.
Adrian
|
|
|
|
|
"Root of the textfile"? In what directory are you putting this text file? What's the file used for? Is it shared between all users of the machine?
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
This textfile is for: my program is to be registered first and i made it, when you click on the button register, automatically the text that has been inputed into the textbox will be transported in the textfile. then when the second time the user opens the program the program will check if theres something in the textfile. if the textfile is not empty then you dont need to register the second time.
This is my register button:
Private Sub btnreg_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnreg.Click
Dim sw As String = ("C:\Adrian\Registration Test\Register.txt")
Dim s As System.IO.StreamWriter = New System.IO.StreamWriter(sw)
Dim obj As frmprogram
Dim text As String
text = txtbox.Text
If text = "" Then
MessageBox.Show("Invalid Entry", "Registration Error", MessageBoxButtons.OK, MessageBoxIcon.Warning)
s.Close()
End If
If text = "" = False Then
MessageBox.Show("You have registered for the program. Now close the registration menu and start using the program. Have Fun!!", "Registration Completed", MessageBoxButtons.OK, MessageBoxIcon.Information)
s.WriteLine(txtbox.Text)
s.Close()
End If
End Sub
End Class
Then this is the program form which will read from the textfile:
Private Sub frmprogram_Activated(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Activated
Dim obj As New Registration
Dim obj1 As frmprogram
Dim sw As System.IO.StreamReader
sw = New System.IO.StreamReader("C:\Adrian\Registration Test\Register.txt")
Dim s As String
s = sw.ReadLine
sw.Close()
If s = "" = True Then
obj.ShowDialog()
End If
If s = "" = False Then
lbltop.Text = "Hello" & " " & s
End If
End Sub
End Class
|
|
|
|
|
You'll have to put the registration file somewhere where a member of the Users group has write permissions. Most of the time, that's the users own home directory under Documents and Settings. But, you'll have to get creative and hide the registration file somewhere else. File based registrations are weak at best. What's to stop any person from just copying the file to another workstation and breaking your registration?
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
I dont think this wouldbe to difficult but can anyone provide me a piece of code to do this: I would like the end result to look like this:
ID,MyName,MyAddrerss,MyAge ect...
|
|
|
|
|
Here is one possible method to write a DataTable to a csv file. If you want to write out a whole
DataSet to csv files, then you could loop through each table in your DataSet and produce
a file for each table.
Hope this helps
Public Sub WriteCsv(dt as datatable, filename as string, delimiter as char)
dim writer as System.IO.StreamWriter
try
writer = new System.IO.StreamWriter(filename)
'write the column names
for i as integer = 0 to dt.Columns.Count - 1
writer.write(dt.Columns(i).ColumnName)
if i <> dt.Columns.Count - 1 then writer.write (delimiter)
next
writer.write(controlchars.newline)
'write the data
For i As Integer = 0 To dt.Rows.Count - 1
For j As Integer = 0 To dt.Columns.Count - 1
writer.Write(dt.Rows(i).Item(j))
If j <> dt.Columns.Count - 1 Then writer.Write(delimiter)
Next
if i <> dt.Rows.Count - 1 then writer.Write(ControlChars.NewLine)
Next
writer.Flush()
writer.Close()
writer = Nothing
Catch ex As Exception
If Not writer Is Nothing Then
writer = Nothing
End If
End Try
End Sub
|
|
|
|
|
Nice one worked a treat..
|
|
|
|
|
Hello
I have a asp.net datagrid with 4 bound columns and an item template column with an image button control. all these columns have the same datasource, i can bind the 4 bound columns just fine to their apporiate columns in the datasource but i am at my wits end as to how to get the correct image url's for all the image buttons in the item template. Please help it's rather urgent
Thank you
|
|
|
|
|
Your question wuold be better handled in the ASP.NET Forum. It has nothing to do with VB.NET...
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
|
|
Hi!
I have a collection where i keep objects of a certain type.From time to time i need to enumerate the collection and access some properties of that object to know if that object is obsolete and remove it from the collection. Many threads manipulate those objects, ones for reading others for writing.
My question is: to assuere thread-safety should i lock the collection or the current Object being processed? I ask this because even though the collection is locked if another thread changes the object directly the lock to the collection is useless!!!
Anyone can help me with this?
Another question: if i have a synchronized version of the collection, if another thread modifies the collection through a synchronized version of the collection will it afect the first thread?
thx in advance
Never say never
|
|
|
|
|
If you synchronize access to the collection, the thread that gets to the collection second will block until the first thread releases its lock.
As is plastered all over the .NET Framework documentation, enumerating a collection is not a thread-safe operation. From the Array class documentation:
Thread Safety
Public static (Shared in Visual Basic) members of this type are safe for multithreaded
operations. Instance members are not guaranteed to be thread-safe.
This implementation does not provide a synchronized (thread-safe) wrapper for an Array;
however, .NET Framework classes based on Array provide their own synchronized version of the
collection using the SyncRoot property.
Enumerating through a collection is intrinsically not a thread-safe procedure. Even when a
collection is synchronized, other threads could still modify the collection, which causes the
enumerator to throw an exception. To guarantee thread safety during enumeration, you can either
lock the collection during the entire enumeration or catch the exceptions resulting from changes
made by other threads.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Hi!
But in order for the second thread to stay blocked i need to put the code in the first thread protected by a syncLock block right?
Never say never
|
|
|
|
|
All of your access to the array much use SyncLock, not just the main thread enumeration. If every access to the array goes through SyncLock, there's no threading issues. So, read up on Array.SyncLock[^]. Put some test code together and play with it!
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
You need to do two things:
1) Ensure that no other thread is actively modifying the collection or any of it's members.
2) Ensure that no other thread is currently reading any collection members since collection access is not inherently threadsafe.
MSDN does a generally poor job of describing thread synchronization in VB.NET. Their examples explain just enough to get you into trouble, mostly.
The problem is a synckLock, aka critical section, will only protect a section of code. If you put a critical section on, for example, the collection Delete method this will ensure that only one thread can delete a collection member at any given time, but it provides no guarantees that other threads are not currently enumerating the collection, so you would still get errors.
The only way you could accomplish thread safe access using a syncLock (aka critical section) with a collection is if you put the syncLock on the enumeration code, AND you ONLY modify a collection or it's members within the For ..Next loop.
This has two very obnoxious side effects:
Of course, only allowing write access within a For .. Each enumeration results in awkward and inefficient code.
All other threads are blocked when a single thread accesses the collection for any reason. What you really want is to only lock the collection when one thread needs to modify it.
So syncLock really is not suitable for this scenario. The correct way to do this is to implement locking if and only if a thread needs to modify the collection.
I'll explain how to do this the old-fashioned way with mutexes and semaphores.
The following procedure will ensure thread safe collection usage with minimal unneccessary locking.
Execute the following steps to "write" protect a collection, i.e. when a thread intends to access the collection for modification.
1) When a thread wishes to modify the collection or it's members it must first acquire a mutex. The mutex is only available to one thread at any given time and is used to block all other threads from either read or write access to the collection.
2) After the "writer" thread acquires the mutex, it must wait until all other threads have released their semaphores which occurs when all other threads which are actively accessing the collection as "readers" have finished.
3) When all semaphores are signalled, the "writer" is ensured it is sole access to the collection and the collection or any of it's members may safely be modified because all other threads are now blocked from read or write access.
4) When the writer is done modifying the collection or any of it's members, it releases the mutex, which unblocks all other threads.
Execute the following steps before any thread accesses the collection for read purposes only.
1) When a thread wishes to read the collection by either item access or enumeration it must first acquire a mutex. If the thread cannot acquire the mutex, it means another thread is possibly writing to the collection, so it must wait.
2) After the "reader" thread acquires the mutex, it should acquire a semaphore to signal to any subsequent writers that a thread is accessing the collection for reads.
3) Release the mutex so the next reader may acquire it long enough to get the next semaphore.
4) When the reader is done accessing the collection or any of it's members, it releases the semaphore.
You should implement all the above actions in a class that wraps your collection and provides thread-safe access to it.
VB.NET provides a ReaderWriterLock class that essentially implements the same operations I describe above behind the scenes. But I suggest you use the Win32 APIs to create your own mutex/semaphore code for synchronization so you can learn how it really works. VB.NET wrappers are fine if you understand threading synchronization fundamentals already. If you don't, you are a lot better off working directly with Win32 primitives.
Robert
|
|
|
|
|
Hi! Thx for the answers.I've used before semaphores and mutexes with C in linux.I wanted a quick way to make sure the concurrency doesn´t raise any problems.
My really problem isn´t how the locking mechanism works, but a "second level" of locking.For example o use sockets read async.When i complete a read i have directly the object which i keep in the collection(along with many others).The thing is that at this point i need to lock just the object, not the entire collection.But when i'm enumerating the collection i lock it because i want to access all objects.So, i'm divided in how i should do that, because if i lock the collection but that in the read function have access to the object i'll be able to modify it!!!That's not right.
Sugestions?
Never say never
|
|
|
|
|
Mutexes and Semaphores will still work. Keep in mind that mutexes and semaphores do not "lock" anything. They are just a means of inter-thread communications.
A mutex says "I am in the process of modifying some object. No other threads should attempt to access this object until I am done". A semaphore says "I am in the process of accessing some object. No other threads should attempt to modify this object until I am done."
The developer still has to write all the code that ensures each thread obeys the rules when accessing an object.
carlos_rocha wrote:
When i complete a read i have directly the object which i keep in the collection(along with many others).The thing is that at this point i need to lock just the object, not the entire collection.But when i'm enumerating the collection i lock it because i want to access all objects.So, i'm divided in how i should do that, because if i lock the collection but that in the read function have access to the object i'll be able to modify it!!!That's not right.
You have to set a reference to the object somewhere. It does not matter if you are enumerating the collection or setting a reference directly to an object that exists in the collection. Before you access a member of the collection by any method of access - direct or by enumeration (both of which require you to set a reference to the object) the thread should acquire a semaphore to notify all other threads that it is accessing an object and they cannot modify any objects or the collection itrself. Before you attempt to modify either an object or the collection itself, a thread must acquire the mutex and wait for all semphores to become signalled. This means that no other thread is actively accessing any object in the collection.
In this scenario, you are not sychronizing the objects themselves, you are synchronizing read and write operations on both the collection itself and all of it's members. This will work as long as you are not frequently modifying data either at the collection level or at the member object level.
If you are frequently modifying member objects then you may find that synchronizing on read and write operations causes excessive wait times. In this case you have to implmement synchronization at two levels - collection add/deletes as a top level and per-object synchronization at the member level. This is a lot more complicated.
Before I would implement this degree of synchronization I would carefully examine my application design. Multiple threads frequently accessing common data for anything other than read only (inherently threadsafe) operations is not a scenario that is generally efficient. Threads are mostly useful only when there are minimal concurrency issues. If your application requires more than minimal synchronization, multi-threading will tend to make it slower than just using a single thread.
Or you need to review your overall design.
For example, suppose your application needs to read a lot of data, populate objects from the raw data, and put them in a collection (or it needs to continuously read data in real-time). The application then modfifies some of the objects. The logical way to multithread this would be to have a background thread read data asynchronously, and populate objects and save them in a local collection. Periodically the background thread should stop reading data, and notify the main thread that it has a new set of objects ready. The main thread then adds the new objects to a collection that it owns exclusively, tells the background thread it has taken ownership of the data, and then the background thread drops all references to the existing objects and goes and gets new data.
Threading is generally only useful in the following scenarios:
Background processing of data passed off from a main thread to a worker thread, for example slow dataset processing/updates using data already modified by the main thread, or preparing a print job.
Background processing of data read from an external source to prepare it to be used by the main application, for example slow queries, downloading data from a webserver, or real time data acquisition systems.
Thread pooling applications that require a thread to be assigned to a given operation to ensure all operations remain responsive. For example an IVR system may assign threads on a per channel basis so that each caller gets a response in a timely manner.
In the first two cases, thread synchronization occurs infrequently - only when threads need to transfer data from one thread to another. In the third case there is no concurrency, each thread acts independently.
Although there are always exceptions, in general if significant thread concurrency issues exist, it probably indicates someone is trying to use threads based on the totally misguided notion that multiple threads will somehow "speed up" an application.
carlos_rocha wrote:
I wanted a quick way to make sure the concurrency doesn´t raise any problems.
Sorry, there is no quick way to ensure concurrency issues don't arise. SynchLocks (critical sections) are deceptively easy to code but are by far the most difficult form of synchronization to use correctly. The only place you'll find "quick ways" are in the MSDN examples which are practically useless in real applications. The MSDN examples do not even bother to show the absolute minimum implementation required to use a SynchLock. Any code that enters a critical section absolutely must have a Finally block to ensure that no matter what happens in the protected code the thread always exits the critical section and releases the lock. The MSDN glosses over even this basic fundamental, much less describing any of the numerous subtleties of using SynchLocks.
Robert
|
|
|
|
|