Topic: Delphi 2 & 3 - INT64

[DanaPaul]

Thanks, but why now, i never get error, do you add that ?

Ummm, (choke) yes.  I find it easier to build code with a bit of error checking rather than ignoring result errors and looking for problems in the wrong area.  However, since you have an existing app, you could comment this error checking statement in the header file.
 

Help me also how to terminate my app. Imposible to call bass_free, i get a "illegal handle error".

Well, that procedure doesn't pass any parameters to Bass.dll.  I suspect it has something to do with Bass internally.  Are you using BASS_STREAM_AUTOFREE?  Perhaps Ian can help with this one.

Also imposible to terminate without error message (i try application.terminate, form.close, ...  always the same result...)

I suspect this is somehow associated with "illegal handle error" when calling BASS_Free.  I'll try some testing to see if I can duplicate this BASS_Free error.

[DanaPaul]

Fred,

It is important that the following constant has a correct, and unique module name in your second BASS header file...

Code: [Select]

implementation
const
 BassDll = 'bass2.dll' + #0;
Also, the following methods should have unique identifiers...

Code: [Select]

procedure Bass2DllLoad;
procedure UnloadBass2Dll;
function CheckBass2Version(dwVer: DWord): DWord;
function IsBass2DllLoaded: boolean;
implementation

[DanaPaul]

Fred,

After you have the second Bass header file cleaned up, consider removing all code from the Finalization sections of both Bass header files.

Apparently the reference counter that Windows API maintains for each mapped module isn't reliable (go figure).  I've changed the posted header files to maintain its own reference counter.  Your app is built solely around Bass so you don't need this functionality.  Removing this code from the Finalization section(s) will suit your purpose.

[fredvs]

Hi DannaPaul.

I have try your new bass_18.pas, it compile, program load, everything seems good, but when i do appliation.terminate, (everything goes well before :, bass_stop, bass_free, etc...) i get a error message : "inval handle" , i click OK then its ok, the app stop, without crash like in your past header.

This is better but...

NB: I dont have try already with your bass2.pas...

[fredvs]

Hi DanaPaul, its me again.

I have noted that the invalid handle message error comes only with application.terminate.

If i use mixk.close (mixk is the main form) instead, everyting goes well, the app terminate without crash.

I will try your bass2.pas...

[fredvs]

Hi DanaPaul

I have change and try bass2.pas, it seems to work.

But i have noted that now the mix and slide are not so fluently and i hear a litle crack at begining of play

Witch variable must i use to store getposition, now i use a comp variable, maybe it there the problem ?

NB I get sometimes the "invalid handle" error message while closing app, i have discard your error raising in your bass.pas for the moment, then no more error message...

[DanaPaul]

I have change and try bass2.pas, it seems to work. But i have noted that now the mix and slide are not so fluently and i hear a litle crack at begining of play

I'm assuming that Bass2.pas is simply a copy of Bass.pas to accomplish a second instance.  In that vein... download the latest header file. That was fixed.  Or, you can edit the (second) header file(s) yourself.  The problem is caused by a missed static binding statement "external".  That function is still loading Bass.dll at launch and binding with Bass.dll, not your second instance, Bass2.dll.

Mia Culpa

Witch variable must i use to store getposition, now i use a comp variable, maybe it there the problem ?

Bass is returning a QWORD, or COMP.

NB I get sometimes the "invalid handle" error message while closing app, i have discard your error raising in your bass.pas for the moment, then no more error message...

That has been fixed in the latest header file upload.

BTW, thank you for your Delphi 3 input

[fredvs]

Hi DP

Your header is perfect   and it help me to find some hidden bugs  

I have recompiled MixK with your header, the new version is on the download page.

Thanks a lot, nice job.

PS : Why have you do that, is it because you think Delphi 3 still the best and the more stable ?

[DanaPaul]

PS : Why have you do that, is it because you think Delphi 3 still the best and the more stable ?

I can't comment about Delphi 3 because I've used Delphi 2 since its initial release.  True, small footprint, fast, easily expandable.  But I think I have stayed with it today because I have no apparent need for the latest technologies, e-commerce, dot (what?) Net, etc.

Perhaps a 64 bit machine will change my attitude, eh?

[fredvs]

I switch between Delphi 2 and 3.
I work with Delphi since the begining (Delphi 1).

I agree totaly with your opinion.

[fredvs]

Hi DanaPaul

Thanks for your beautiful work.

With Delphi3, you use USE_64_ASM variable in place of built-in-false-64-bit COMP.

But you said also that to use it you must do a assembler procedure and that takes a litle time for the processor.

Perhaps it is a stupid question, but is i possible for your header to make the distinction of the valor > comp then use ASM else use COMP ? :-/

[DanaPaul]

Fred,

You want both? The ASM routines for full 64 bit precision and direct binding with Bass.dll using COMP (32 bit precision) for speed?

There are any number of ways to accomplish this.

1) If you don't want ASM 64 bit precision in the Multi Bass header files...

 A) Comment the conditional directives by placing a period after the leading bracket... {.$define USE_64_ASM}

 B) Undefine the directives after their definition ($undef USE_64_ASM}

 C) Define a directive of your own at the compiler options page named "SPEED_TEST" and place this in the header file after the original directives...
 {$ifdef SPEED_TEST}
   {$undef USE_64_ASM}
 {$endif SPEED_TEST}

2) If you want both methods, 64 bit ASM precision and direct (32 bit) binding with Bass.dll for speed then you could create identical functions under a slightly different name and then use GetProcAddress to bind these new functions...

BASS_ChannelSeconds2Bytes and FAST_ChannelSeconds2Bytes

BASS_ChannelGetPosition and FAST_ChannelGetPosition

BASS_StreamGetLength and FAST_StreamGetLength

In my humble opinion, this speed penalty is neglible. However, I plan to implement separate strategies with the Multi instance and Single instance Bass header files.  The Multi will have no error checking and bind directly with Bass(exception, these few functions mentioned above with D2 & D3). The single instance header files will have full error checking and (hopefully) become a good learning tool for Delphi/Bass.

[fredvs]

Whouaw   superb, they are lots of kings in those threads, it is exactly what i want...

Thanks a lot DP, i will dream of you this night (and of your codes of course)...

Very, very impressioned...

[DanaPaul]

BASS2_ChannelSetPosition ;
 
I get a BASS2_ERROR_POSITION : raise EBass2Exception.Create(sSeekPositionIllegal);

Ummm... found it Fred... A sporatic problem may exist if Windows blows away the registers that Delphi 2 and 3 use in GetPosition calls.  So if your SetPosition call was generating a new position based GetPosition then this could account for a sporatic seek error.

This has been fixed in the latest header file upload (today).  However, I am uploading a new (final) header file that will incorporate full error checking by raising plenty of exceptions.  Per chance you are not interested with trapping all of these Exceptions, I will save a copy of the header file that has the GetFilePosition fix before full error checking.  If you want a copy of this quick fix please let me know and I'll e-mail it to you.

[DanaPaul]

The single instance Bass header files have been optimized and now carry the last modification date annotated in the files.

http://members.aol.com/wtgdana/private/Bass/

These latest modifications include full error checking for Bass, BassWMA, and BassCD return results published in their respective help documentation.  The following validations are also included...

Float type outgoing and incoming parameter checking for possible NAN (not-a-number) errors.

LoadModule collision between BassWMA/BassCD, and additional validation that Bass is already loaded. Module names are checked in compliance with module naming conventions specified in the C+ header files.

These single instance header files are formatted to be as interchangeable as possible with the multiple instance header files already posted.

No further update notifications will be posted in this forum.  However, all bugs should continue to be reported

[fredvs]

Hi DanaPaul

If you want a copy of this quick fix please let me know and I'll e-mail it to you.

With pleasure. fiens@hotmail.com

[fredvs]

Hi DP

With your new header i get a succesion of "Invalid handle" for each bass function loaded, then the app crash  

NB For EACH function, even with those that im shure are ok.

[DanaPaul]

With your new header i get a succesion of "Invalid handle" for each bass function loaded, then the app crash  

Huh?  Where is this error originating from?  Practically every 4 byte integer is a handle in Windows API.

Do you have "Show Exceptions" enabled in Delphi?

[fredvs]

Hi DP

Do you have "Show Exceptions" enabled in Delphi?

I dont see that in Delphi D3 Tools-Environement Options.

The error occur with

round((loword(BASS_ChannelGetLevel(str))

.

And if i remove that function, the error occur at the first "BASS_ChannelSetPosition" ,if i remove that function, the error occur at the first "BASS_ChannelGetPosition" , if i...

[DanaPaul]

I dont see that in Delphi D3 Tools-Environement Options.

Are you seeing any Exceptions with the new header file? There should be plenty.  It would seem odd that your Delphi doesn't show exceptions.

And if i remove that function, the error occur at the first "BASS_ChannelSetPosition" ,if i remove that function, the error occur at the first "BASS_ChannelGetPosition" , if i...

Either Bass.dll didn't load and the handle for the Bass module is (zero) invalid, this should have raised an exception...

Or the Bass channel handle is (zero) invalid and this should have raised an exception as well.

[DanaPaul]

Fred,

Set a breakpoint at the first line in the Bass.pas header file to be sure that the unit is initializing...

Initialization

 RefCount := 0;
 doLoad_BASS := True;
 BASS_Handle := 0;
 InitProcPointers; { Initialize proc pointers }

[fredvs]

Hi DP

No, always "handle is not valid".  :-/

(No such problem with your version 03/05/19 23:05 108k and before, perhaps your change in loaddllbass in bassloaddll (or reverse, i dont remember ?))

[DanaPaul]

No, always "handle is not valid".  :-/

No = in reference to what?

(No such problem with your version 03/05/19 23:05 108k and before)

Exceptions are extremely useful when building code, and very mysterious if you are hiding them. Example...

BassLoad
BASS_Init()   <- (except raised, execution stopped)
hChannel = BASS_CreateStream() (this won't execute)

I suspect that your Delphi options are set to hide exceptions, or your code is trapping ALL exceptions (bad practice) or you have installed a component that is doing a poor job of inserting itself as an Exception handler.

[fredvs]

Hi DP

No = in reference to what?

= reference to breakpoint, it dont change nothing.

Sorry, i will seem a beginner with Delphi, but i dont know what you say about

I suspect that your Delphi options are set to hide exceptions

, i dont see the option, : Tools- Exception... in my Delphi 3 Client-server version even not in my Delphi 2 version...

or you have installed a component that is doing a poor job of inserting itself as an Exception handler

You make me afraid, MixK have now more than 60.000 lines... :-/

[DanaPaul]

= reference to breakpoint, it dont change nothing.

Ummm, your app can't use this header file, nor any unit that utilizes Initialization sections, if execution ignores this basic functionality during EXE launch.  These Initialization and Finalization sections equate to API call AddExitProc, or the inverse of

I've seen some Delphi components that insert themselves as Application handlers, some do a better job than others...

Application.OnException
Application.OnExecute
Application.OnHint
Application.OnMessage
etc...

Improper use of these functions can adversely affect your application(s).