|
wave file can be add to project as resources but mp3 i cant played it as resources ....what the problem with mp3 can anyone help me with that please
|
|
|
|
|
1. One exclamation sign suffices if not separated from last word.
2. What have you tried to play the mp3 in question? What error messages (if any) did you see?
After getting the Play part to work, you can deal with attaching the file to your project's resources pretty easily.
Ciao,
luker
|
|
|
|
|
i try to add mp3 file to resources without open dialog its not work ..
after i add wav file to resources i played it with :
SoundPlayer sndplayr = new SoundPlayer(resource.Properties.Resources.xp);
sndplayr.Play();
and i try :
System.Reflection.Assembly a = System.Reflection.Assembly.GetExecutingAssembly();
System.IO.Stream s = a.GetManifestResourceStream("xp.wav");
SoundPlayer player = new SoundPlayer(s);
player.Play();
wave file played but mp3 i can't .. is that any method to do it ..
|
|
|
|
|
You can embed anything (well, any file or finite stream which can be saved as a file) as a resource. I don't think there is native MP3 playing in the Framework, though.
|
|
|
|
|
AFAIK (and MSDN[^] is pretty categorical about it) SoundPlayer can't handle MP3's - you would need to use a MediaPlayer embed to play them. The problem with that is that MediaPlayer only works with files: it has no facility to work with streams. So, you would need to export the MP3 from your resources into a temporary file, play it, then clean up after yourself when you are finished. Which defeats the purpose of having the file as a resource in the first place!
There is an alternative solution here: http://stackoverflow.com/questions/184683/play-audio-from-a-stream-using-c-sharp[^] but I haven't tried it and can't vouch for it's effectiveness! 
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
i look about it but i don't understand anything i m newer in C# can you help me please with that in a little sample cod project ?
|
|
|
|
|
If you don't understand the link I gave you, then probably the best thing to do is put this project on the shelf for a while - just until you understand a bit more about the basics - otherwise you will probably end up missing something important and never learn it!
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
This is a repost of the question I responded to here[^].
|
|
|
|
|
I can't believe, this is the same guy.
|
|
|
|
|
I know, hence my comment.
|
|
|
|
|
Repost! do not repost your questions here.
***** Programme comme si dept soutien technique. est plein de tueurs en série et ils savent adresse de votre domicile. *****
|
|
|
|
|
When my background thread calls the following code,
public void Func(object Request, object Response)
{
if (this.InvokeRequired)
{
this.Invoke(new ResponseHandlerDelegate(ResponseHandler), new object[] { Request, Response });
return;
}
}
does the background thread get blocked at the Invoke call until the UI thread completes the function call?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Yes, the calling thread will block.
If this behaviour is not desired, you can circumvent it by using BeginInvoke instead of Invoke.
Ciao,
luker
|
|
|
|
|
And if I use BeginInvoke, can I "stack" multiple calls to BeginInvoke before any of them completes?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
You can, but be aware that this can lead to unpredictable results as they might not complete in the order you expect.
|
|
|
|
|
How true is this? Two calls to BeginInvoke from the same thread will execute in the order you called them in, I would imagine. And calls from different threads don't have a natural concept of before/after anyway, so it wouldn't matter.
|
|
|
|
|
They may start in the order you requested, but how do you know what order they finish in?
|
|
|
|
|
Correct me if I am wrong but all call will all run in the same thread.
That is in the thread of the control you are invoking.
As they are queued, I can't see how they could finish in a different order from the order they started.
|
|
|
|
|
|
I read the post I agree with you Luc. You can't predict in which order the methods will be run.
What I was trying to say is that they will complete in the order they start.
thread A: Control1.BeginInvoke DoSomething(1)
thread B: Control1.BeginInvoke DoSomething(2)
thread C: Control1.BeginInvoke DoSomething(3)
... sometime later
Control1's thread: Start Running DoSomething(1)
Control1's thread: End DoSomething(1)
Control1's thread: Start Running DoSomething(3)
Control1's thread: End DoSomething(3)
Control1's thread: Start Running DoSomething(2)
Control1's thread: End DoSomething(2)
I am not sure if it is clearer. What I want to say is that two calls to DoSomething won't happen simultaneously if they are called using Invoke.
|
|
|
|
|
Pascal Ganaye wrote: two calls to DoSomething won't happen simultaneously if they are called using Invoke.
Unless DoSomething() calls Application.DoEvents() (or something similar such as GetMessage), then the actions would probably still start in the intended order but not finish in that order, as now a later one could start and finish before an earlier one had a chance to finish. That is exactly why DoEvents is such an atrocious beast.
|
|
|
|
|
As Pascal says, all the UI updates will be in one thread, so once one has started, the rest must queue behind it.
|
|
|
|
|
Be careful! An Application.DoEvents() can cause the second call to overtake the first. And when it is not you to have placed such evil statements in the code, some Third Party components may contain them... Really a fun to debug that!
|
|
|
|
|
It's true. A while back we wrote an application that received inputs from a number of sensors, and these had to be plotted on a graph. The sensors were receiving on different threads, and items were being written to the display in the wrong order. While they were being logged in the right order, the person watching the display was seeing a distorted view of the sensor readings.
|
|
|
|
|
I'm curious, how did you solve that? Did you find some way to serialize the threads?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
