You're right that if playing 20 Files where each file will have a lenght of its name of about 64 chars this would end up in senseless memory on the heap of about 19files*(64ytes*2UnicodeCharLenght) = 2432bytes = 2,432Kb (approx.!)
So I did catch your point that it's the way to avoid such senseless Heap occupation of 2,432Kb in case of 19 used files. of Ok so far. Right?
Do this more than once and you have a problem, you run out of memory and your program grows and grows in memory size. Unless you end your program than PB (as I understand) frees the memory!!
Please clearify: Do you mean a bug in PB according the heap? Cause if not ... I cant reproduce (according to your statement "Do this more than once") that an application could run out of memory if for instance 2,432Kb are unused stored on the heap? Or did I miss something?
I do assume that Traumatic maybe also did not bother about such a small amount of unused but allocated Kb's (just imho).
So how many files including very big filename string lenghts are you about to load? Cause if beeing exact my HTPC for example will be switched off after watching/listening Media for several hours or if a timer based recording has been finished.
Dont get me wrong I see your "declare as global" way as 100% correct but with the little risk that maybe these defined globals could be also used by the user using the same name without beeing aware of it in his further code where the include has been loaded into. Thats why I tried to avoid any globals in an include file I do provide official.
So the quintessence was/is that someone has to choose between the compromise of some KBs unused on the heap ... and the risk of declaring pointers as globals where you dont know what pointer names the user will use in his later code.
In C/C++ where codeparts can be compiled & linked as .obj's to libs/dlls/exes where such Global pointers wont mix up things by using auto or static in the obj's ... there this wont be such an issue unless you force to access the value in the other obj. by using "extern".
AFAIK PB generates "one" asm file out of the whole user code where this resulting single obj. containing everything of the user code will be linked with the needed libraries.
.... just imho based on my actual programming knowlege
PS: All this could be avoided by including the WideChar data into the Directshow_Media Structure below, where the L() function comes with an added argument of a pointer to the Structure where that unicode string will be stored and finally also be deleted when freeing the memory within the FreeMedia() Command.
Code: Select all
#MaxWcFilenameLenght = 512 ; 512 chars should be enough for a wc filename?
Structure Dshow_Interfaces
pGraphBuilder.IGraphBuilder
pControl.IMediaControl
pEvent.IMediaEventEx
pWindow.IVideoWindow
pAudio.IBasicAudio
pVideo.IBasicVideo2
pSeeking.IMediaSeeking
WideCharFileName.w[#MaxWcFilenameLenght]
EndStructure
..
..
..
Procedure InitMedia()
Protected a, b, c, d, e, f
*p.Dshow_Interfaces = AllocateMemory(SizeOf(Dshow_Interfaces))
...
...
...
ProcedureReturn *p
...
...
...
EndProcedure
...
...
...
Procedure.l L(*p.Dshow_Interfaces, string.s) ; Ansi->Unicode
If string and p
PokeS(@*p\WideCharFileName[0], string, Len(string), #PB_Unicode)
Endif
EndProcedure
...
..
...
Procedure FreeMedia(*p.Dshow_Interfaces)
Protected pfs.l
If *p
*p\pControl\GetState(10,@pfs)
If Not pfs = #State_Stopped
*p\pControl\stop()
EndIf
*p\pSeeking\Release()
*p\pVideo\Release()
*p\pAudio\Release()
*p\pWindow\Release()
*p\pEvent\Release()
*p\pControl\Release()
*p\pGraphBuilder\Release()
FreeMemory(*p)
CoUninitialize_()
ProcedureReturn = #True
Else
ProcedureReturn = #False
EndIf
EndProcedure
Like this? (just written straight out of head far away from my Windows pc as Im at work using a MAC
)
