|
|
is there other way to write
NewBitmap.SetPixel(x, y, Color.FromArgb(Clamp((int)Red, 255, 0), Clamp((int)Green, 255, 0), Clamp((int)Blue, 255, 0)));
without the use of clamp?
|
|
|
|
|
|
|
this will do the trick:
private static int Clamp(int Value, int Max, int Min)<br />
{<br />
Value = Value > Max ? Max : Value;<br />
Value = Value < Min ? Min : Value;<br />
return Value;<br />
}
|
|
|
|
|
|
Take a look inside the source code for the article you referenced. I haven't tried it personally, but it appears that the author provided the code to create and compile the control.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Well I am working on my first Clients / Server application. First I started off working with syncronous sockets, and then switched to asyncronous sockets. The way it looks like it is going to work for now (until I get a better understanding) is the Client connects to server, Client sends data to server, Server gets data, Server looks for data pertaining to that specific client, Server returns data to client, connections close and end.
I see a problem though? What if the client connects to the server, sends data to server, server gets it, then server loses connection to the internet?
This would mean that my client is stuck on the BeginReceive part. I can't find a timeout. Now I haven't tried to test this yet.. but I was wondering how to handle this situation? Would syncronous sockets be better than asyncronous?
|
|
|
|
|
Hi Jacob,
this is how I see it:
1.
there are no synchronous or asynchronous sockets, all sockets are the same; however you can operate them in sync or async way; you can choose your way separately for clients and servers.
2.
you can always mimic an async operation by launching a separate thread that works synchronously. The disadvantage is cost (one more thread, with its state and stack), the advantage is comfort, as you have less of a problem remembering your state.
3.
The .NET Socket class supports ReceiveTimeout in sync mode only; when using the async methods, if you want some kind of timeout, you have to implement it yourself. And even then, it will not pre-empt an outstanding async Receive, all it will do is tell your app sooner the data isn't coming (in time).
4.
Assuming your client is using only one or a few sockets at any point in time, I don't see much objections to using the thread and sync mode there. On the server side, the potential number of clients may force you to work in async mode.
Hope this helps.
|
|
|
|
|
Ok thanks!
My server could possibly be accepting 50-100 connections. If you have agents out there checking in every 2-5 minutes. So I should implement the asyncronous method on the server end, and use syncronous on the client? That way I can specify a timeout and won't get in a situation like I mentioned above. Do you see any real objections to doing something like that?
|
|
|
|
|
Yes, that is what I would do in a first iteration, as it keeps the clients simple, and optimizes the server.
|
|
|
|
|
Awesome! Thanks for the replies. I will use async on server side and sync on client side.
|
|
|
|
|
You're welcome.
|
|
|
|
|
Hi, Can you please tell me how I can access the controls of a form from a WCF service? The forms application and the service reside in one solution as seperate projects and I added wcf service the necessary reference to forms project but still I'm not able to access the controls(controls are public). Your valuable suggestions are welcomed.
Thanks!
|
|
|
|
|
Can't be done. The WCF service is running in a seperate process, usually on a seperate machine.
If the service needs access to the controls, it's up to your client app to pass the required values in.
Seriously, no code outside of the form the controls sit on should ever need to access the controls of a form.
|
|
|
|
|
You can't and shouldn't access them directly as has already been said.
If your Forms app is receiving messages from the service then it can respond to those messages and update it's controls itself.
|
|
|
|
|
I prefer to have the Service generate an XML file that the clients read.
|
|
|
|
|
Hi,
First of all, are you sure that's what you want to do? Why? Sorry for asking this, but I believe it's not, and unless you provide a context, I don't know if i'm helping or throwing you a rope to hang yourself.
But to answer your question, you can create an instance of the form in the service's class, and it will be available in that service's context.
Now, I believe you want to publish the form data on the web. Here's how i'd go about it:
1. Keep both projects separated (not in the solution, just reference wise);
2. Implement methods on the web service that let you submit form data through them;
3. Make your forms application a client of the webservice;
4. As the controls on the form are filled, send changes to the web service;
5. All clients of the web service will be able to see those changes.
Hope i helped.
Regards
|
|
|
|
|
hi, thanks for detailed info. Here is my case: this is an internet cafe software and I want to send the time info to clients at specific intervals. The controls that I need to access are created and added to the mainform in form's load event. And the mainform is a singleton. Normally I can access it by; MainForm.Instance.Control
I don't ask for ready code, please just show me the way
Thanks in advance
|
|
|
|
|
Hi again,
Well, start by creating a method in your Forms project that does just that, recieves the time info, and updates the controls. You can do this with
public void updateTime(int timeSpan){
for each(Control c in this.Controls){
c.doSomething();
}
}
then, all you need to do is spawn a thread that wakes up every few minutes (or whatever period of time you want) and access the web service and retrieve the time information from your server. When it wakes up, it calls the method mentioned earlier.
The code i'm about to throw in here is by no means a product of good coding practices and will definitelly have bugs as i'm writing it directly on the reply from here at CodeProject, but might just do the trick.
public class Scheduler : Thread {
private Form parentForm;
private "WebServiceProxy" webServiceProxy;
public Scheduler(Form mainForm){
this.parentForm = mainForm;
this.webServiceProxy = new "WebServiceProxy"();
}
public override void Run() {
while(true) {
int timeSpan = webServiceProxy.getTimeSpan();
sleep(5000);
}
}
}
Now add an instance of the Scheduler to your main form.
In the constructor of your form (or at the InitializeComponent method) initialize the Scheduler field and call the Run() method on it.
Try it for yourself.
Hope it helps
|
|
|
|
|
Thanks for your help si24803!
|
|
|
|
|
It would be possible for you to use a duplex WCF service, and make your form implement a callback interface. Wouldn't put any UI types in your interface though. Generally this isn't a terribly scalable approach however.
|
|
|
|
|
I get this error when trying to send something between two apps over TCP.
The weird part is that I can send one time without any trouble, but whenever I try a second time, I get this error.
I use this code for the sending app:
private void B_Send_Click(object sender, EventArgs e)
{
string send = "";
send = TB_Quotes.Text;
TcpClient tcp = new TcpClient(TB_Host.Text, (int)UD_Port.Value);
NetworkStream ns = tcp.GetStream();
StreamWriter writer = new StreamWriter(ns);
writer.WriteLine(send);
writer.Flush();
ns.Close();
writer.Close();
tcp.Close();
}
And this code for the receiving app:
public Form1()
{
InitializeComponent();
Thread treceive = new Thread(new ThreadStart(Listen));
treceive.Start();
}
public void Listen()
{
int port = 2112;
string result = "";
IPAddress localaddress = IPAddress.Parse("127.0.0.1");
TcpListener listener = new TcpListener(localaddress, port);
listener.Start();
TcpClient client = listener.AcceptTcpClient();
NetworkStream ns = client.GetStream();
StreamReader reader = new StreamReader(ns);
result = reader.ReadToEnd();
Invoke(new UpdateDisplayDelegate(UpdateDisplay), new object[] {result});
}
public void UpdateDisplay(string text)
{
TB_Quotes.Text = text;
}
I'm making sure the port is 2112 (if not, the first time would not be successful), but I don't understand why the 2nd time won't work.
Thanks.
|
|
|
|
|
The Listen method ends after the Invoke bit at the end (also terminating the started thread). Thus it can
not accept new connections (client = listener.AcceptTcpClient(). You'd have to have some kind of loop
where the server continually accepts connections. From within the loop you could start threads that do the
handling for each individual connection.
Cheers
Manfred
|
|
|
|
|
Thanks.
I added a loop and now it works just fine.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
