|
Look into "exit codes"
example[^]
Don't follow just one thread, read up on it a little, before jumping in.
|
|
|
|
|
I am beginner.
and I am going to make my own audio player without using "windows media player"
Please help me to finding me complete tutorial for making own audio player.
|
|
|
|
|
Chaman Saini wrote: and I am going to make my own audio player without using "windows media player"
Please help me to finding me complete tutorial for making own audio player.
I suggest you try the built-in class called "soundplayer[^]".
There's little chance that you'll find a "complete" tutorial on writing your own audio player. If you really want to use something else, try looking for an open-source library.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Request you not to repost.
|
|
|
|
|
|
Hello
I wanna ask that what is the reason that I am not able to play the mp3 file.
my whole code for the "class" for simple audio player is as below:-
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;
namespace myplayer
{
class Player
{
[DllImport("winmm.dll")]
private static extern long mciSendString(string lpstrCommand, StringBuilder lpstrReturnString, int uReturnLength, int hwndCallback);
public void open(string file)
{
string command = "open\"" + file + "\" type mpegvideo alias MediaFile";
mciSendString(command, null, 0, 0);
}
public void play()
{
string command = "play MediaFile";
mciSendString(command, null, 0,0);
}
public void stop()
{
string command = "stop MediaFile";
mciSendString(command, null, 0, 0);
command = "close MediaFile";
mciSendString(command, null, 0, 0);
}
}
}
|
|
|
|
|
One obvious problem is that you don't have a space between open and the opening question mark of the file name in your open method.
|
|
|
|
|
please write your correct code here.
|
|
|
|
|
There's no need for that. What he described is spot on.
Look at the open command you're sending:
string command = "open\"" + file + "\" type mpegvideo alias MediaFile";
There is no space between the word "open" and the first quote mark where you sepcify the file name!
The result is your open command looks like this:
open"somefilename.mpg" type mpegvideo alias MediaFile
instead of this:
open "somefilename.mpg" type mpegvideo alias MediaFile
What do you think you have to do to fix that little problem??
|
|
|
|
|
hmmm Thank you so much Buddy.....
I am a beginner so i had face that problem 
|
|
|
|
|
but it is still not workin.....I mean it is not playing............
What should I explain so that I can achieve more from you....
|
|
|
|
|
You're sending null in place of a buffer to hold any return information, so you're basically not getting any error information back from MCI.
You might also want to try removing the "type mpegvideo" from your command to see if that does anything.
|
|
|
|
|
You main problem is that you do not check the response from your mciSendString commands so you have no idea whether any of them have succeeded.
|
|
|
|
|
Recently, I had to track down why all of our new WPF screens were leaking memory. I rapidly dove into this issue and soon discovered that this issue was dispeared after I run the FOLLOWING code.
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
Does .net not call the method?
I use the GC.CollectionCount method to get the number of times garbage collection has occurred for the 0/1/2 generation of objects and find they were 211/196/9.
It means .net Does do it.
Can somone tell me why it is occured?
PS: I have a test by open and closing 10+ screens, my app consumed 200+MB from task manager. According to the .net memory profiler and ANTS memory profiler, the objects created by my screens have been actually collected.
I also tested that if we forced a GC(Garbage Collector) collect by above codes, the memory will be reduced obviously.
Thanks,
Michael.
GC;Memory Leak
modified 21-Feb-13 21:08pm.
|
|
|
|
|
Whenever you run GC.Collect(), only those objects that are not referenced anywhere are collected.
The numbers that you observe are those that are not cleared.
|
|
|
|
|
For the most part .net GC "just works" in .net, obviously this doesn't happen in all cases. It is rare to need to do an explicit GC. This[^] is probably worth a read. The most relevant part to this question is when GC takes place, to quote:
- The system has low physical memory.
- The memory that is used by allocated objects on the managed heap surpasses an acceptable threshold. This means that a threshold of acceptable memory usage has been exceeded on the managed heap. This threshold is continuously adjusted as the process runs.
- The GC.Collect method is called. In almost all cases, you do not have to call this method, because the garbage collector runs continuously. This method is primarily used for unique situations and testing.
When one of these happens, GC takes place.
If you do something that takes up a lot of memory then it can be a good idea to GC, but it is generally discouraged. This is really a tuning thing and depends on your app, if the performance is degraded then you probably do need it.
Hope this answers your question.
|
|
|
|
|
micwu wrote: Can somone tell me why it is occured?
Without seeing your code base, no. I'm going to take a wild guess here that you have strong event handlers that aren't being released, or you possibly have an issue with data bindings not being cleared from items such as the DataGrid. Attach a profiler, run the application and investigate the issues. What you currently have here is masking the real problem.
|
|
|
|
|
I have a test by open and closing 10+ screens, my app consumed 200+MB from task manager. According to the .net memory profiler and ANTS memory profiler, the objects created by my screens are actually ok-to-collected.
I also tested that if we forced a GC (Garbage Collector) collect by following codes, the memory will be reduced obviously, back to the memory volume level before screens are open.
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
|
|
|
|
|
Never, ever, use Task Manager as a means of determining whether or not your application is leaking memory. Unless you are looking at the Private Bytes allocation, what you see in Task Manager is the amount of memory that has been allocated to your application by .NET for it to potentially use. This isn't memory that's in use, it's memory that your application could use if it needed to. The thing about this memory allocation is that the runtime can take it back if it needs to, so it's possible to watch wildly varying memory depending on the load on your system.
|
|
|
|
|
The question nobody has asked is what makes you think it's leaking memory?? Did you look at Task Manager or run this under a memory profiler? Hint: One of these lies to you when looking at a .NET app.
|
|
|
|
|
I had a test by open and closing 10+ screens, my app consumed 200+MB from task manager. And according to the tool .Net Memory Profiler and ANTS Memory Profiler, the objects created by my screens are actually ok-to-collected.
|
|
|
|
|
If Windows wants the memory back, the .NET CLR is more than happy to collect and return as much as it can. The GC will also run whenever it gets a sense that it "can" and/or needs to. It's, really, very good at its job. You can see an example of this just by watching the Task Manager and launching your app, then minimizing it.
The CLR will try to keep a pool of memory (managed heaps) available for your apps object allocations. Objects that are collected get the memory returned back to the managed heap, NOT to Windows. This keeps allocation speeds fast compared to allocating a block of memory from Windows, adding it to the heap, and then allocating your object. If the memory is already in the heap, there's no round-trip to Windows to get the memory first.
What Task Manager is showing you is how much memory is RESERVED by the .NET CLR for your app, not how much your app is actually using. But, like I said, if Windows needs the memory back for any reason, the .NET CLR is more than happy to give as much back as it can. You really don't need to worry about what you see in Task Manager. It's not representative of what your app is actually doing and should not be used to generate your applications system requirements.
|
|
|
|
|
If you have third-party plugins or are using old (unmanaged) code this might be the culprit.
I'm pretty sure you can write .Net (managed) code that has memory leaks, but in that case you probably did something funky. I doubt standard WPF code has memory leaks.
|
|
|
|
|
I think maybe there is no memory leak for my app but .Net GC doesn’t run the collect as we expected.
|
|
|
|
|
Long ago, I run into OutOfMemory exceptions when doing a lot of graphics operations. After adding some calls to the Garbage Collection, especially GC.WaitForPendingFinalizers();, the problems were gone, the maximum memory use was reduced to less than a tenth of the capacity of the computer. My impression is that garbage collection just happens to slowly in such a case.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
