|
This problem occurs also when you are using inherited forms. Forms inherited from forms in your own project usually don't cause much trouble. But I have never been able to inherit a form from another (library) project... the program worked just fine - like yours - but the designer wouldn't work...
A bug in VS.NET ...
Anybody knowing how to fix this inheriting problem??
greetz 
*Niels Penneman*
Software/Dev Site
Personal Site
|
|
|
|
|
I can't seem to figure this out.
I need to dispose the audio after it has finished playing(using DirectX).
ourAudio = new Audio(fileName);
if (ourAudio != null)
ourAudio.Play();
<- NEED SOMTHING HERE (Wait function or Thread...)
ourAudio.Dispose();
Thanks
Thomas
|
|
|
|
|
Handle the Audio.Stopping event. In the handler, you could call ourAudio.Dispose, or to use the handler for multiple Audio.Stopping events, cast the sender parameter (could be any name, but it's the first parameter in the handler) to an Audio Type and call Dispose:
private void PlaySound(string fileName)
{
ourAudio = new Audio(fileName);
ourAudio.Stopping += new EventHandler(audio_Stopping);
ourAudio.Play();
}
private void audio_Stopping(object sender, EventArgs e)
{
Audio a = sender as Audio;
if (a != null) a.Dispose();
}
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Hi,
I have to develop a client/server application in C#. The connection between the server and the client hast to be persistent and encrypted. There will be steady dataflow on push basis from the server.
My question is, what is the best approach to build this kind of application? Speed is one of the most important factors.
I read an article about Bear Stearns who built their new stock market transaction server as XML web service.
So, if anybody has some gnereal ideas i'd greatly appreciate that
|
|
|
|
|
I suggest to read about Remoting. I just finished a client/server application using remoting and it works very good.
You can persist and encrypt using Remoting.
Search in CP about remoting.
Visit www.ingorammer.com[^]
Free your mind...
|
|
|
|
|
I did but to me it looked more like remoting is used to offload processing to another computer.
What I want are persistent connections for a couple hundred clients, constantly pushing or pulling data.
So, this will be very performance critical.
What are the other possibilities to approach this type of application?
However, I'll have a deeper look at remoting and see whether it suits my needs
|
|
|
|
|
Try webservices, but webservices will work for pulling data, as you know it works using a web server, and the web server can't send information to the clients, unless the client ask for the information.
I used remoting to push and pull info from the server and the clients.
Free your mind...
|
|
|
|
|
That's the reason why I can't use web services as the data hast to be pushed to the client.
What about developing an own TCP/IP Server... do you see any benefit in doing this?
|
|
|
|
|
This was already discussed elsewhere I think. I'll give you some advice: don't develop a server which handles each client in a separate thread, cause that will cause processor overloading with >20 clients.
Maybe you'll find the answer at .NET 247 
greetz
*Niels Penneman*
Software/Dev Site
Personal Site
|
|
|
|
|
hm but every client will receive different data concurrently. How else could this be accomplished without threads?
|
|
|
|
|
Sorry, it does require multiple threads, but make sure you are not running 200 threads at once, you'll have to pool / manage your threads... But that's something I - too (i guess) - am not familiar with.
greetz
*Niels Penneman*
Software/Dev Site
Personal Site
|
|
|
|
|
Why invent the wheel when you already have rockets going to mars ???
That's up to you, but remoting is very robust.
Any way, if you need an example, I can send you some code.
Free your mind...
|
|
|
|
|
I agree with the first reply that .NET Remoting is worth looking into, but there is another, easier alternative.
You can use XML Web Services over HTTPS (HTTP over SSL) if your server has a valid certificate. If you're developing an internal application and have ActiveDirectory, you (or IT) can use the Certificate Services to create a Web Server certificate and install it in IIS. For external applications, I recommend getting an SSL cert from VeriSign, Thawte, or any other certificate authorities (CAs). Then, just make sure you use a URL to access your Web Servce using the https scheme instead of http. It is automatically encrypted without you having to do anything.
If you do look into .NET Remoting - which is far more robust, though WS Security is certainly providing additional features for Web Services - I recommend a good book for both new and intermediate Remoting developers from Microsoft Press, ".NET Remoting" by McLean, Naftel, and Williams: http://www.microsoft.com/mspress/books/6172.asp[^]. You could use channel sinks to encrypt, compress, route, or anything else to the messages in an abstract manner. This book cover that and even includes an example channel sink and derivative RealProxy for doing basic load balancing. It's a good book!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
thanks for both your replies. I'll definitely have a deeper look at remoting.
Unfortunately I can not use XML Web Services as i have to push date from the server to the client.
|
|
|
|
|
You want this book as reffed in this thread, it shows an implementation of an encrytion sink for remoting in Chapter 9.
Remoting does seem to be your answer.
DTrent
|
|
|
|
|
The snippet below seems to me to reek of inelegance, yet i have no better solution. i can't manage with using {} because the pictureBox barfs if i dispose the image too soon.
Is there a better way??
Image disposeOfSoon = pictureBox.Image;
pictureBox.Image = newImage;
if (disposeOfSoon != null) disposeOfSoon.Dispose ();
________________________________________
Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain.
Then perhaps I'd deserve ya, and be even worthy of ya..
if I only had a brain!
|
|
|
|
|
Image disposeOfSoon = pictureBox.Image;<br />
using (disposeOfSoon)<br />
{<br />
pictureBox.Image = newImage; <br />
}
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
I'm not sure if that works, but if it does, its totally ludicrous!!!
1. IMO the variable shouldnt leave the using block.
2. No object was created, only referenced.
leppie::AllocCPArticle("Zee blog");
Seen on my Campus BBS: Linux is free...coz no-one wants to pay for it.
|
|
|
|
|
I have to be honest that I could not see the point myself with the original code. So I guessed its not real and just an example.
in terms of your points:
1. the variable does not leave the using block...
2. calling dispose on an object which is pointing at a image works, as all you are doing is asking the image object to call dispose - which is worth doing if you don't want it anymore.
hope this makes sense, or else I've misunderstood your points 
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
The code is real, it describes a common situation: a picture box displays an image for some unspecified duration, then in response to some event the image should change. AFAIK this requires the soon-to-be-old current image be pointed to, the new image be displayed, and the now-old-current image be disposed. Surely this is a common problem. Nes pas?
________________________________________
Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain.
Then perhaps I'd deserve ya, and be even worthy of ya..
if I only had a brain!
|
|
|
|
|
Philip Fitzsimons wrote:
the variable does not leave the using block...
What I meant to say was the variable was enclosed, iow declared too. Thus the compiler can pickup a problem readily.
Philip Fitzsimons wrote:
calling dispose on an object which is pointing at a image works, as all you are doing is asking the image object to call dispose - which is worth doing if you don't want it anymore.
Its all and well, but not if it someone elses object that mite need to exist after the method returns. Refer to above. IMO the object should be sandboxed in the scope.
leppie::AllocCPArticle("Zee blog");
Seen on my Campus BBS: Linux is free...coz no-one wants to pay for it.
|
|
|
|
|
i agree in principle with what you're saying, that's why i wrote the post. the problem is that there isn't any good local "scope" for the image, once the pictureBox gets it it should belong to the pictureBox. perhaps i should write PictureBoxEx.. (yecch!!)
btw the snippet provided by Philip Fitzsimons "looks" kinda wierd but works great! if we could get EricGu to rename the keyword "using" to "noLongerUsing" the snippet would read:
Image tmp;
noLongerUsing (tmp = pictureBox.Image)
{pictureBox.Image = aBrandNewImage;}
________________________________________
Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain.
Then perhaps I'd deserve ya, and be even worthy of ya..
if I only had a brain!
|
|
|
|
|
 what are the design tradeoffs between different constructs to collect objects based on some common functionality?
Suppose i want to rely on objects being able to "display" themselves. What's the difference between using Abstract Base, Interface, or Attribute? Since c# doesnt allow multiple inheritance i'd guess Abstract base should be reserved for "core" properties of the object, and i guess Interfaces are there exactly so my displayThyself methods can be expressed. What about [Serializable], that has properties similar to an interface except for specifying a constructor as one of the mandatory methods.
Is there a discussion of what construct to use when and why?
Thanks in advance!
________________________________________
Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain.
Then perhaps I'd deserve ya, and be even worthy of ya..
if I only had a brain!
|
|
|
|
|
TuringTest1 wrote:
i'd guess Abstract base should be reserved for "core" properties of the object
Yes.
TuringTest1 wrote:
i guess Interfaces are there exactly so my displayThyself methods can be expressed.
Well,you mention that multiple inheritance is not allowed in C#,with Interfaces you can have multiple inheritane,you inherit a class from another class AND how many interface you want.
Serializable word express itself.It means you can seriallize this class. MSDN exapain these things very good,you can start from it.
Mazy
No sig. available now.
|
|
|
|
|
Mazdak wrote:
Serializable word express itself.It means you can seriallize this class. MSDN exapain these things very good,you can start from it.
yes, [Serializable] is implemented as an attribute, but it really looks like an Interface, doesn't it? except that for technical reasons (one of the 2 interface "methods" is a constructor) it can't be an interface. Or something like that. What are the similarities and differences between something implemented as an Interface and something like [Serializable] which is implemented via attributes?
________________________________________
Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain.
Then perhaps I'd deserve ya, and be even worthy of ya..
if I only had a brain!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
