|
Given the question thats a bit unlikely I suspect 
Bob
Ashfield Consultants Ltd
|
|
|
|
|
Hi!
I have a serious problem.
I have some text that is written by a TextRenderer. And now i want on some part of it an link with underline, different color and so on.
I have searched many hours but found nothing.
Has somebody a solution?
|
|
|
|
|
The color, underline etc of a link is control by the style. You can define what these attributes are by using styles, preferably in CSS. If you want the code for the actual link google for href, that should get you going.
Bob
Ashfield Consultants Ltd
|
|
|
|
|
thanks for your answer.
the problem is, that i want to make a part of the text clickable. i don't know how to insert a link in the text the textrenderer produced.
have you got an idea about this?
|
|
|
|
|
Yes, as I said, you need to put the link text in a href - just like any link. If you dont know what I mean, just google for href. How you put in around your text in a textrenderer is for you to work out.
Bob
Ashfield Consultants Ltd
|
|
|
|
|
hello,
is it a way to share variables between c# and sql server 2005
best regards
dghdfghdfghdfghdgh
|
|
|
|
|
You can share values, not variables, in a certain number of ways. Via SQL tables, for instance.
|
|
|
|
|
i have created a user control Dynamically and added it to panel as a child. now if i remoove it from panel but it still remains in memory.
i want it to be permanently removed from memory. There is no Dispose method available. and i also tried by implementing idisposable interface and overwriting the Dispose() method but it still remain in memory.
Is there any way to remove this object(User Control) from memory
Regards
Rishi
|
|
|
|
|
RishiKasnia wrote: There is no Dispose method available.
AFAIK, UserControls inherited from IDisposable and have a Dispose() method.
I died as a mineral and became a plant,
I died as plant and rose to animal,
I died as animal and I was Man.
Why should I fear? When was I less by dying?
-- Rumi[^]
My blog
|
|
|
|
|
Thanks Pedram Behroozi
You r right.
Actually i was developing a Windows Appl Using WPF.
in my case i need to remove this user control from memory . becoz after removing it from canvas or panel , if i try to fire some event then this Control also respond the event (Though it has been removed).
for a workaround i detached the Event Handler for user control(when i remove it from canvas/panel). but it still resides in memory and remains throughout the program execution (becoz this control is not local to any Block) thus degrading performance .
Regards
Rishi
|
|
|
|
|
Well I know nothing about WPF UserControls and unfortunately I can't help you.
I think it's better for you to ask it in WPF / WCF / WF Forum[^].
Regards
I died as a mineral and became a plant,
I died as plant and rose to animal,
I died as animal and I was Man.
Why should I fear? When was I less by dying?
-- Rumi[^]
My blog
|
|
|
|
|
It ok Pedram Behroozi
i have also posted the problem in WPF section but did't get any resonable ans.
anyways thanks.
|
|
|
|
|
Removing instances from memory is the Garbage Collector's job. You don't have much control over when that gets done. But you can do cleanups inside the Dispose method. So basically you remove your event handlers in the Dispose method, and simply calle the Dispose method when you remove your control from the panel. (Typically Dispose is called for all the controls in a Form from within the Close method of the Form).
Also if you control is hanging around in memory long after you have removed it, it could mean that you have some references to it somewhere in your program.
|
|
|
|
|
I didn't realise you were using WPF.
WPF controls don't have Dispose methods because they don't need them. WPF controls don't use any unmanaged resources.
To release the memory used by a WPF control all you have to do is make sure you have no references to it, and the garbage collector will automatically clear up all the memory next time it runs.
Events are something to watch out for. Remember that the event source holds a reference to the event sink, so yes if you have a control sinking events from a source on a main form, then you will need to make sure you detach the event handlers if you want the control to be released.
Note that the garbage collector does not immediately remove the object from memory. the GC only runs occasionally, and when there is a requirement for more memory than is available. This is normal behaviour and there is nothing wrong with it. if you want to test things you can call GC.Collect() to force a collection and see if your memory is cleared up, but you shouldn't leave this in the code when you release it. The GC is carefully balanced, and forcing unnecessary collections can really screw up it's performance.
If you are still having problems getting the object to be cleared up, you can use WinDbg and SOS to peer deeper into the objects on the heap and work out why they aren't being collected. (Getting started with WinDbg & SOS[^],
How to find a GC leak[^], Memory leak detection in .Net[^])
Simon
|
|
|
|
|
Thanks Simon
|
|
|
|
|
Hello,
Are there side effects of setting Socket.ReceiveBufferSize to a large value (e.g. 50 MB)?
I am writing an application to receive and process a large amount of data. Instead of writing code to read data asynchronously, I was thinking of setting Socket.ReceiveBufferSize to a large number. I am not worried about consuming system resources since the program will run on a dedicated machine. However, I am not sure whether this might have a negative effect over performance, or any other side effects that I should take care of.
FWIW, my application simply uses StreamReader.ReadLine() over the socket's network stream.
Thanks a lot
|
|
|
|
|
What do you hope to gain by setting the receive buffer size that large?
Even if the system lets you do it, it will most likely hurt performance.
Why not try it and see what happens?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
By setting the receive buffer so large, I am hoping to avoid having to read data in a thread and process it in another one. At certain (and few) instances of time, I will be receiving 3X data, where X is the amount of data I can process per second. However, right following that, there will be 0.1X data for some time. So, instead of having to synchronize reader and processor threads, I was hoping the system buffer could just hold the additional data for me.
Meanwhile, I don't think I can test performance right now, because there are many other factors that I might not be able to control. So, why do you think it would hurt performance?
Thanks for your help.
|
|
|
|
|
AFAIK, Windows Sockets will let you set it to a max size of 1MB.
The receive buffer isn't meant to be a data store.
For best TCP/IP performance, your user-mode code should remove ("receive")
data from the socket ASAP. i.e. Send buffer should be full, receive buffer should
be empty.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
hello,
Do someone know an algorithm for generating a smard card numbers composed from 14 numbers
best regards
dghdfghdfghdfghdgh
|
|
|
|
|
I have a TcpClient connection that connects to a local java process. When I close the form, I call dispose on my tcp client handler and kill the java process. However, this is causing the below error:
11:22:01 TcpClientHandler.Read; IOException: System.IO.IOException: Unable to read data from the transport connection: A blocking operation was interrupted by a call to WSACancelBlockingCall. ---> System.Net.Sockets.SocketException: A blocking operation was interrupted by a call to WSACancelBlockingCall
>>>> at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
>>>> at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
>>>> --- End of inner exception stack trace ---
>>>> at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
>>>> at System.IO.StreamReader.ReadBuffer()
>>>> at System.IO.StreamReader.ReadLine()
I am a bit confused as to why this error is being thrown, since when I close the form, the "Reading..." trace is never printed out.
public void Read()
{
Trace.WriteLine("##debug: Reading...", "INFORMATION");
try
{
do
{
_alertMessage = _reader.ReadLine();
if (!string.IsNullOrEmpty(_alertMessage))
{
if (MessageReadEvent != null)
MessageReadEvent(this, _alertMessage);
}
}
while (!string.IsNullOrEmpty(_alertMessage));
}
catch (IOException io)
{
Trace.WriteLine(MethodBase.GetCurrentMethod().DeclaringType.Name + "." + MethodInfo.GetCurrentMethod().Name +
"; IOException: " + io.ToString(), "ERROR");
}
}
When I dispose of the tcp client handler I dispose of the reader, and then call tcpClient.Close();
Regards,
Gareth.
(FKA gareth111)
|
|
|
|
|
Gareth H wrote: and then call tcpClient.Close();
No way to say this doesn't get people upset but, developing quality software can ONLY be accomplished by reading the documentation, period.
link[^]
When you are finished sending and receiving data, use the Shutdown method to disable the Socket. After calling Shutdown, call the Close method to release all resources associated with the Socket.
Gareth H wrote: I am a bit confused as to why this error is being thrown, since when I close the form, the "Reading..." trace is never printed out.
I can't explain how your code works. A wild guess is that it did print out long before you closed anything and you just are not seeing it because you are mistakenly expecting to see it print out when you close the form. That said, an exception will be thrown from a blocking read when the read is canceled. That behavior is by design.
led mike
|
|
|
|
|
I added the Shutdown call, but that didn't solve the problem. It seems that the exception is thrown the same number of times a message is sent to the java process. So, if I send 5 messages, 5 exceptions are thrown when the form is closed.
Regards,
Gareth.
(FKA gareth111)
|
|
|
|
|
Gareth H wrote: I added the Shutdown call, but that didn't solve the problem.
Did you read my post? 
led mike wrote: That said, an exception will be thrown from a blocking read when the read is canceled. That behavior is by design.
Gareth H wrote: It seems that the exception is thrown the same number of times a message is sent to the java process.
Without being able to reproduce the behavior themselves it is unlikely anyone will be able to help you. I have done socket development since 1994 and I have never seen anything such as you describe. My first guess is that the behavior is introduced by your code, not by the TCP stack or the any of the other libraries you are using.
Some of what you previously said indicates you are using threads. It is very likely you are creating a new reading thread for each message sent to the Java process since that would explain the behavior.
led mike
|
|
|
|
|
I solved the problem. Changed my Read() method to create a StreamReader in a using block.
Regards,
Gareth.
(FKA gareth111)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
