Compiling Cactus Jukebox with Lazarus 2.2.6 (Error: identifier idents no member)

[Roland57]

Hello everybody!

I would like to compile Cactus Jukebox with Lazarus 2.2.6 (under Linux).

I could solve by myself almost all compilation errors, but I don't know what to do with this one:

Code: Pascal  [Select][+][-]

1. // source/plugin/impl/cj_interfaces_impl.pas
2. procedure TCJ_TrayIcon_Impl.ShowNotification(AImageList :Integer; Icon :Integer; Msg :PChar; Sound :PChar);
3. begin
4.   if (AImageList=-1)
5.      then AImageList :=global_vars.ImageListNormal.Handle; // cj_interfaces_impl.pas(515,52) Error: identifier idents no member "Handle"

Would someone know how to fix that procedure?

[jamie]

I guess the logical approach would be to open that file and examine the class the handle is in?

Maybe it's sitting within a private section?

[Roland57]

Here is the variable declaration.

Code: Pascal  [Select][+][-]

1. // global_vars.pas
2. Var
3.    ImageListNormal      :TImageList;

[cdbc]

Hi
Does 'TImageList' surface a public property 'Handle'?!?
If not, there's your problem...
Regards Benny

[jamie]

I don't see a handle in there.
 
I suspect that maybe that package had its own imagelist.

look at the supplied units that come with it.

[Roland57]

I found an explanation and a solution here. Problem solved.

[cdbc]

Hi
Good, that you found a solution 
I mean: Who in their right(or wrong) mind, would have thought that this:

Code: Pascal  [Select][+][-]

1. ImageList1.ResolutionByIndex[0].Reference.Handle

is the answer to your question...?!?
>blip< 
Regards Benny

[dsiders]

Hi
Good, that you found a solution 
I mean: Who in their right(or wrong) mind, would have thought that this:

Code: Pascal  [Select][+][-]

1. ImageList1.ResolutionByIndex[0].Reference.Handle

is the answer to your question...?!?
>blip< 
Regards Benny

Noted. It looks like TImageList docs could use a little touch up. But it is mentioned in the TCustomImageList.Reference and TCustomImageListResolution.Reference topics.

https://lazarus-ccr.sourceforge.io/docs/lcl/imglist/tcustomimagelist.reference.html
https://lazarus-ccr.sourceforge.io/docs/lcl/imglist/tcustomimagelistresolution.reference.html

[JuhaManninen]

How could the code compile earlier? I guess it worked years ago.
The fix should go to CCR in SourceForge. The maintainer of Cactus Jukebox, Felipe, has not been active for some time.

[Roland57]

The fix should go to CCR in SourceForge. The maintainer of Cactus Jukebox, Felipe, has not been active for some time.

I uploaded the updated project here. (One can check the modifications that I have made here.)

[JuhaManninen]

I finally tested Cactus Jukebox with Lazarus trunk + FPC 3.2.2.
Yes, there are many errors. Functions found in LazUTF8 are called but LazUTF8 is not in the uses sections. How did it ever work?

Then there is :

Code: Pascal  [Select][+][-]

1. mainform.pas(515,16) Error: Duplicate identifier "Finished"

Apparently "Finished" was added also to TThread at some point.
I decided to remove the variable and use the one inherited from TThread.

It works very well now. Maybe I start to use it regularly. FYI: MPlayer must be installed.
I committed the changes. I have commit rights to CCR although I did not use them for a while.
Please test.
I also added Handle back to TCustomImageList for the next major version.

@Roland57, you pushed a backup directory and your session .lps file. The session contains things like a local editor file history which are usually not meant to be shared.

Everybody, please provide patches for CCR applications and components. They can be maintained collectively although many of their maintainers are gone.

[wp]

Functions found in LazUTF8 are called but LazUTF8 is not in the uses sections. How did it ever work?

There was a lot of movement of functions between units recently. Maybe they were not in LazUTF8 in previous versions?

There is one problem maintaining CCR sources: unlike LCL or other packages distributed with Lazarus, CCR is not linked to a specific Lazarus version, and it cannot be assumed the a particular function is available in the user's installation. Of course CCR packages cannot be supported back for an "unlimited time". There is no commonly accepted agreement on that. I myself would not attempt to support Laz v1.x, but Laz v2.x is not too old and, therefore, I would always try to support it by adding LCLVersion directives to the code.

[Roland57]

I committed the changes. I have commit rights to CCR although I did not use them for a while.
Please test.

Compiled successfully under Linux with Lazarus 2.2.6.

I also added Handle back to TCustomImageList for the next major version.

Good to know.

@Roland57, you pushed a backup directory and your session .lps file. The session contains things like a local editor file history which are usually not meant to be shared.

Yes, I saw that. Thank you.

[JuhaManninen]

There was a lot of movement of functions between units recently. Maybe they were not in LazUTF8 in previous versions?

Functions were moved to LazUTF8 a very long time ago.
Well, Cactus Jukebox also has not been maintained for a very long time. Considering that, it was quite easy to bring up to date.

There is one problem maintaining CCR sources: unlike LCL or other packages distributed with Lazarus, CCR is not linked to a specific Lazarus version, and it cannot be assumed the a particular function is available in the user's installation. Of course CCR packages cannot be supported back for an "unlimited time". There is no commonly accepted agreement on that. I myself would not attempt to support Laz v1.x, but Laz v2.x is not too old and, therefore, I would always try to support it by adding LCLVersion directives to the code.

Lazarus itself supports 2 last versions of FPC. Maybe CCR code should support LCL and other Lazarus packages for 3 last versions, considering the release cycle is faster.
It is not a big issue really. Most people update their Lazarus in a reasonable time scale. If somebody wants to peek into the history, Sourceforge revision control allows that.

[wp]

I tested the cactusjukebox now myself. It compiles and runs with all Lazarus versions after 2.0 and FPC after 3.2.0. There was a run-time error due to an attempt to convert an empty string to a float, and I noticed that the player did not stop when the program ends which leads to a "lost" MPlayer process in the Windows task manager and prevented to start the jukeboxplayer a second time. Both issues fixed.