Wrapping RC6 in a TB moniker. Potential dangers?

Hello fellow developers,

I'm currently working on adapting my VB6 application to support 64-bit systems, particularly for integrating with 64-bit SAPI voices. I've been using TwinBasic to create wrappers that enable 64-bit compatibility for my existing VB6 classes requiring to be 64 bit.

It worked amazingly well, and I have also created a wrapper around Chilkat using the same approach. This solved the problem of crashes involving pressing the Stop button of VB6 IDE which would not properly close Chilkat threat pool and thus crashing the VB6 IDE.

I've come across an issue where I need to transition from a c32bppdib class image list to using RichClient6's Cairo.ImageList, which supports only one instance per application. To overcome this limitation, I am considering wrapping RC6 in a TwinBasic wrapper, which would theoretically allow me to instantiate multiple Cairo.ImageLists.

Here’s what I am thinking about:

• Wrapping the entire RC6 library to manage multiple instances of Cairo.ImageList.
• Ensuring each instance remains isolated and doesn’t interfere with others.
• Concerns:

• Are there potential pitfalls in wrapping RC6 that I should be aware of, particularly with memory management or performance?
• Could this approach lead to unexpected behavior given that RC6 is typically designed to handle only one imagelist per application?

I would appreciate any insights or advice on this matter. Has anyone else tried something similar, or can anyone foresee potential issues with this approach?

Link for reference: RichClient6 (RC6)

Thank you in advance for your help!

RC6 is currently 32bit only.

I would use a 32 bit wrapper for that.

Quote:

---

Originally Posted by tmighty2

...using RichClient6's Cairo.ImageList, which supports only one instance per application.
To overcome this limitation, I am considering wrapping RC6 in a TwinBasic wrapper,
which would theoretically allow me to instantiate multiple Cairo.ImageLists.

---

That's total overkill - since you can use multiple cCollection-instances,
to "group" (or "separate") your Image-Resources into different "Container-Objects".

Cairo.ImageList is a simple wrapper around a cCollection as well...
(it just stores multiple cCairoSurface-instances under different StringKeys inside).

Here's an example for a cCollection-based ImageContainer:

Dim MyImgList1 As cCollection
Set MyImgList1 = New_c.Collection(False)

MyImgList1.Add Cairo.ImageList.AddImage("", FileName), "MyImageKey"

...what I've marked red above, is the Cairo.ImageList - delivering the loaded resource as a cCairoSurface
(using an empty String-Key)... the new Surface-Object then added under your own Key into your own cCollection-instance.

For renderings (out of your own cCollection-based ImageCaches) you would then do:
CC.RenderSurfaceContent MyImgList1("MyImageKey"), x, y

Olaf