[vbRichClient] How To...

[yogiyang]

I am starting this thread with a hope that all the users who are using vbRichClient will post all their queries here on this thread.

How to use cFSO?

I am trying to use the class cFSO present vbRC5 but I keep getting Error.

Here is the code:

Dim myFSO As vbRichClient5.cFSO
  
  Set myFSO = New cFSO      '<= VB complains with Invalid use of New Keyword
  
  Call myFSO.CopyFile("C:\Mytest.txt", "C:\MyTest001.txt")

If I comment out the second line I get the error 91 - Object variable or With block variable not set.

if I write like this:

Call vbRichClient5.cFSO.CopyFile("C:\Mytest.txt", "C:\MyTest001.txt")

I get error Method or member not found.

Can someone help solve this please.

TIA

Yogi Yang

[Carlos Rocha]

I also had troubles when trying to instantiate it directly. You must use cContructor, or the global function New_C() that returns a new cConstructor, like New_C().FSO

[Schmidt]

Thanks to Carlos for helping out...

And yes, one of the main-things to "get straight" first with RC5-usage is, that not all Classes of the RichClient are directly instantiatable per New-Operator
(some of them are - but those are mostly "early ones" - like the SQLite or Collection/Dictionary-classes, who made their way into the library already some years ago).

Though (as Carlos has pointed out already), *all* of the offered RC5-classes (as they are listed e.g. in the VB-ObjectExplorer) can
be instantiated over a Constructor-Helper, which is of type cConstructor and (in VB and VBA) always available per New_c.

@yogiyang
Your:

    Call vbRichClient5.cFSO.CopyFile("C:\Mytest.txt", "C:\MyTest001.txt")

can be simply changed to

    Call New_c.FSO.CopyFile("C:\Mytest.txt", "C:\MyTest001.txt")

As said, New_c is an "AutoObject" (a GlobalMultiUse-Class of Type cConstructor) which is available anywhere in your VB-Code without declaring it -
I named it New_c, to resemble the New-Operator which is normally used in VB, to create an Object-Instance.

E.g. the cSortedDictionary is a Class which can be instantiated "both ways":

    Dim D As cSortedDictionary

Normally per VBs New-Operator:

    Set D = New cSortedDictionary

or per New_c Constructor-Helper:

   Set D = New_c.SortedDictionary

I hope, the resemblance is obvious and now more easily understood - and I'd like to
encourage the usage of New_c throughout your whole project (instead of normal VB New-Operator),
because it is then much easier, to switch to regfree-mode - but it is also more convenient, since many
constructor-methods have Optional Parameters, which allow to specify certain "Intitial Properties" of the
Object which is about to be created - this saves some Lines of Code quite often.

And in case of the New_c.FSO-method ... this is a special case which hands out always the *same* instance -
so there's no call-overhead due to constantly re-instantiating a new cFSO-instance - you will get always the
same instance back - and thus don't need to buffer an FSO-instance in your own MyFSO-variable - so there's
no Dim Declaration necessary at all in this case.

This behaviour is not the default on most of the other Object-Instancings, the New_c (cConstructor) normally
hands out new created, fresh instances to you - but since the FSO is used quite often (and doesn't have internal state,
it's just a "Method-Namespace", so to say) - there was an exception made.

Long story short - anywhere in your code you'll have an already preinstantiated FSO-instance available at your fingertips -
(without Diming) and you can do direct calls as shown above: New_c.FSO.WhateverFileMethodYouNeedFromFSO

Olaf

[DrUnicode]

I tried cFSO Class but it returns the infamous "???" for Unicode names.
I would be willing to fix this but there is no source code available for cFSO.
Might also want to add Boolean "IsReady" Property and Boolean "IsUSB".
Screenshot using my class (Unicode aware) looks like this using cwVList widget.



Another nifty thing you can do is to SubClass the Vb6 hidden window and process message WM_DEVICECHANGE and wParam DBT_DEVICEARRIVAL, DBT_DEVICEREMOVECOMPLETE to refresh the Drive List when you plug/unplug USB devices.

[Schmidt]

I tried cFSO Class but it returns the infamous "???" for Unicode names.

cFSO is Unicode-aware implemented internally - and shouldn't give you any "???" - but (according to your nice cwVList-ScreenShot)
I assume you mean the Method cFSO.GetDriveFriendlyName(...)?

Here's the implementation behind it ...:

Public Function GetDriveFriendlyName(sDrive, Optional SysName As String, Optional SerialNum As Long, Optional SysFlags As Long, Optional ComponentLength As Long) As String
Dim VolName As String, S As String
  If Len(sDrive) < 1 Then Exit Function
  S = Left$(sDrive, 1) & ":\"
  VolName = String$(MAX_PATH, 0)
  SysName = String$(MAX_PATH, 0)
  
  If GetVolumeInformationW(StrPtr(S), _
                           StrPtr(VolName), MAX_PATH, SerialNum, ComponentLength, SysFlags, _
                           StrPtr(SysName), MAX_PATH) Then
    VolName = Left$(VolName, InStr(VolName, vbNullChar) - 1)
    SysName = Left$(SysName, InStr(SysName, vbNullChar) - 1)
    GetDriveFriendlyName = StrConv(VolName, vbProperCase)
  End If
End Function

...only thing that comes to mind - now that I consider the last line -
is that the StrConv function in conjunction with the vbProperCase-Flag is perhaps not behaving
unicode-aware (never tested this, just silently assumed that it is)...

Would be nice, if you could test StrConv with vbProperCase within your test-setup and your Unicode-VolumeNames
...could then apply an appropriate fix for "Proper casing" - or just hand out VolName directly as the Function-result.

Another nifty thing you can do is to SubClass the Vb6 hidden window and process message WM_DEVICECHANGE and wParam DBT_DEVICEARRIVAL, DBT_DEVICEREMOVECOMPLETE to refresh the Drive List when you plug/unplug USB devices.

Ah - Ok, maybe in the next version ...

Olaf

[DrUnicode]

I tested here and Yes, StrConv with vbProperCase Flag does indeed trash the Unicode "ようこそ" into "????".
I think returning VolName directly as the Function-result would be best.

cwDirList and cwFileList also are returning "???" for Unicode. Perhaps there is a StrConv in New_c.FSO.GetDirList?

[Schmidt]

I tested here and Yes, StrConv with vbProperCase Flag does indeed trash the Unicode "ようこそ" into "????".
I think returning VolName directly as the Function-result would be best.

cwDirList and cwFileList also are returning "???" for Unicode. Perhaps there is a StrConv in New_c.FSO.GetDirList?

Ok, both things fixed now in new version 5.0.9 of the RC5-BaseDll-package (the latter problem was in vbRichClient5.dll too, not in vbWidgets.dll) -
so - yeah, just download anew here:
http://www.vbrichclient.com/Downloads/vbRC5BaseDlls.zip

Olaf

[DrUnicode]

Attached is Drive project using latest vbRichClient 5.0.9 with cFSO fixes for Unicode.
Vb6 Hidden Window is SubClassed, so try to plug/unplug a USB device and it should automatically refresh the list.

[Schmidt]

Thank you very much for the contribution of another RC5-Demo - all seems to work (including the AutoRefresh in conjunction with USB-Drive-detection/removal) -
and well, you even used the RC5-Subclasser for it.

Have so far just taken a look at the Form-Code-Module - but seems all pretty nice there (with regards to "best practice of
RC5- and Widget-usage" - only thing which can be done a bit more directly is the Form-Centering-Code:

Form.CenterOn Form.WidgetRoot.CurrentMonitor

Would like to include the enhanced Drive-Handling (and Drive-Info-methods) into the cFSO of the (mid of next year expected)
version 6 of the RichClient (if you don't mind).

obrigado novamente, Saúde

Olaf

[Bonnie West]

Another nifty thing you can do is to SubClass the Vb6 hidden window and process message WM_DEVICECHANGE and wParam DBT_DEVICEARRIVAL, DBT_DEVICEREMOVECOMPLETE to refresh the Drive List when you plug/unplug USB devices.

Subclassing ThunderMain doesn't seem to be necessary; regular Forms and MDIForms will do just fine. I believe even the cWidgetForm used in your attached project should also be able to receive the WM_DEVICECHANGE message. In fact, as long as there is a top-level window in an app (it doesn't have to be unowned), the system will send that message to that window.

BTW, in case someone needs to get a handle to ThunderMain, here's a simple class module that obtains ThunderMain's hWnd without using a callback function.

[Schmidt]

Subclassing ThunderMain doesn't seem to be necessary; regular Forms and MDIForms will do just fine. I believe even the cWidgetForm used in your attached project should also be able to receive the WM_DEVICECHANGE message. In fact, as long as there is a top-level window in an app (it doesn't have to be unowned), the system will send that message to that window.

BTW, in case someone needs to get a handle to ThunderMain, here's a simple class module that obtains ThunderMain's hWnd without using a callback function.

Sure, in case you have the Code directly in the GUI-project, then there's usually a hWnd "readily available somewhere".
But in case of e.g. a Dll-Project (and if you want to avoid requiring the passing of an "external hWnd" in a Class-Interface),
then the always available ThunderMain-hWnd is useful.

Expanding a bit on your Code (and the App.Title-idea) in the link above, I think the following should be sufficient as well
(working for all VB-Versions, which have an App-Object, as VB5/6 and VBA)

Private Declare Function FindWindowW& Lib "user32" (Optional ByVal pClsName&, Optional ByVal pWndName&)
 
Public Property Get ThunderMain() As Long
Static stHWnd As Long
  If stHWnd = 0 Then 'let's check that only once (if not yet resolved)
    App.Title = vbCr & vbTab & vbLf & App.Title 'prefix the Title with 3 unusual chars
      stHWnd = FindWindowW(0, StrPtr(App.Title)) 'leave out the ClsName, since Title is unique enough
    App.Title = Mid$(App.Title, 4) 'restore the original Title
  End If
  ThunderMain = stHWnd
End Property

Edit: Ha, with regards to the small Code-snippet above ... I've stumbled over my own argument (that Dll-projects are different).

The above works, but only in a GUI-project, not in a Dll (a Dll has its own App-Object with its own App-Title - but then
the App-Object of the GUI-project takes preference (with regards to the "associated ThunderMain-WindowTitle").

So, as a conclusion... for GUI-free-Dll-Encapsulations the EnumThreadWindows-approach is perhaps still the best one (with the least surprises).


Olaf

[DrUnicode]

I was using Hidden window because the code to detect drive change originally was in a UserControl.
If it is eventually going to be incorporated into vbRichClient DLL then you would probably still want to use the Hidden Window.

[7edm]

I would say vbRichClient is too great to keep covered in only one topic thread and think it's better to "tag" each topic with "vbRichClient" as well as putting [vbRichClient] in the subject, but I will take the opportunity to bump this thread and put in my wish.

It would be nice, to start with, to have some tuts or sample projects covering the "Outs and Ins" of RC5 cCollection, cArrayList and possibly also cSortedDictionary (where it differs) as they could do so much good replacement work in many VB6 projects, and then the Sqlite lib, as I believe it would bring so much more recognition and usage of the vbRichClient as an extension of VB6 - Of course, it's possible to check the library browser and figure things out, but even that is often a daunting task as there are so much advanced goodies berried there, put in by Olaf's genius mind ;-) I fear too few have found it, or rather too many misses it because of the lacking documentation, unfortunately. I can just say that this library is priceless in it's utterly true sense.

Yes there is the cairo samples and for the other new stuff with widgets and forms etc. and it's fantastic, very promising for the future BUT I don't think that's where a large majority of VB6 users coming here are treading right now... so please, don't forget to crown the fantastic work you already have done, Olaf. As an example, dhRichCLient3 had if not many but a decent batch of sample projects that got you started with much of the basic stuff, but this now seem to have gone lost with RC5, please bring it back updated to cover the improvements since.

Then an opinion, I can't see the logic in 'cCollection.CompatibleToVBCollection = True' as a Default value, it's counter productive in my eyes. Ok, I understand it can be "convenient", to start with, but once you have passed the "newbee" stage you have to waste one line of code every time you create a new instance of the object setting it to False. In my eyes, this is not a "replacement" but an "extension" of the VB6 Collection object, and it's great that you can set it to compatibility - when needed, but that should be it.

/Joakim Schramm

[DrUnicode]

I would say vbRichClient is too great to keep covered in only one topic thread and think it's better to "tag" each topic with "vbRichClient" as well as putting [vbRichClient] in the subject, but I will take the opportunity to bump this thread and put in my wish.

It would be nice, to start with, to have some tuts or sample projects covering the "Outs and Ins" of RC5 cCollection, cArrayList and possibly also cSortedDictionary (where it differs) as they could do so much good replacement work in many VB6 projects, and then the Sqlite lib, as I believe it would bring so much more recognition and usage of the vbRichClient as an extension of VB6 - Of course, it's possible to check the library browser and figure things out, but even that is often a daunting task as there are so much advanced goodies berried there, put in by Olaf's genius mind ;-) I fear too few have found it, or rather too many misses it because of the lacking documentation, unfortunately. I can just say that this library is priceless in it's utterly true sense.

Yes there is the cairo samples and for the other new stuff with widgets and forms etc. and it's fantastic, very promising for the future BUT I don't think that's where a large majority of VB6 users coming here are treading right now... so please, don't forget to crown the fantastic work you already have done, Olaf. As an example, dhRichCLient3 had if not many but a decent batch of sample projects that got you started with much of the basic stuff, but this now seem to have gone lost with RC5, please bring it back updated to cover the improvements since.

Then an opinion, I can't see the logic in 'cCollection.CompatibleToVBCollection = True' as a Default value, it's counter productive in my eyes. Ok, I understand it can be "convenient", to start with, but once you have passed the "newbee" stage you have to waste one line of code every time you create a new instance of the object setting it to False. In my eyes, this is not a "replacement" but an "extension" of the VB6 Collection object, and it's great that you can set it to compatibility - when needed, but that should be it.

/Joakim Schramm

Please take a look at the 2 vbRichClient5/vbWidgets demo projects I posted in CodeBank:

http://www.vbforums.com/showthread.p...Doughnut-style
http://www.vbforums.com/showthread.p...tiColumn-Icons

[7edm]

@DrUnicode: I don't want to sound negative, and I do appreciate you replying and your contribution, but when it comes to the library classes mentioned above there is really not much there to learn about usage. The first project have only some simple usage of cCollection in replace of the VB Collection object adding simple text making it a more advanced array. These are the thing you can pick up from the VB6 docs and not really what I advertised for here. Besides, imho uncommented sample code lose much of its educational value.

/JS

[Carlos Rocha]

It's just an idea, and maybe one should wait for a word from Olaf (I don't even know if it's possible), but...what about a GitHub project connected to Olaf's vbWidgets to host samples and findings, in a way that anyone could contribute and put some light in vbRichClient usage?

[7edm]

Just noticed Olaf got Banned (as an outcome of this thread: http://www.vbforums.com/showthread.p...nd-Performance), so let's hope we will come back once the ban is lifted. Otherwise, the idea isn't bad but as you said not sure if it could work. There is already the VF code bank of course but I don't know how he would like to have it.

[yogiyang]

Just noticed Olaf got Banned (as an outcome of this thread: http://www.vbforums.com/showthread.p...nd-Performance), so let's hope we will come back once the ban is lifted. Otherwise, the idea isn't bad but as you said not sure if it could work. There is already the VF code bank of course but I don't know how he would like to have it.

Oh! that is bad news.

[yogiyang]

When can we use TestMode available in VBRichClient?

Are there any possibilities of using VBRichClient for sending and receiving information to and from a web page on server?

TIA

Yogi Yang

[Schmidt]

When can we use TestMode available in VBRichClient?

Do you mean the "DesignMode" for Widgets (in a surrounding Form-Designer)?
Such a thing was begun - though not yet ready.

Are there any possibilities of using VBRichClient for sending and receiving information to and from a web page on server?

For talking to a WebServer you can either use the cDownloads/cDownload-Classes
which come with the RC5 (those would be working with caching-behaviour) -
or if you want to avoid caching of http-responses, then using the "MS Win-http 5.1 Object",
would work equally well.

Aside from that, there's also the RC5-RPC-Classes which cover both, the Clientside
and the Serverside for high-performance AppServer-scenarios (working cross-machine,
usually in a LAN - it's kinda like "DCOM the easy way" what they offer).

Olaf

[tmighty2]

My software heavily relies on images. They are being displayed in various sections. Some section's images are continously being replaced (for example at a mouse click) with others while some stay forever.

I am currently using multiple LaVolpe imagelists for each section so that I can destroy them if their images are no longer needed while I don't have to touch the ones that don't change.

I want to switch to Cairo, but this is only 1 single imagelist in Cairo, right? "Cairo.ImageList"

I wonder how I could use it and still be able to maintain some separation.
I guess I could use keys like "Section1Group1ImageGUIDXYX" when adding images but that looks weird, and I am not sure how removing images would be done... I would iterate over the entire image list and remove images and thus changing indexes, right?

Thank you for suggestions!

[Schmidt]

I want to switch to Cairo, but this is only 1 single imagelist in Cairo, right? "Cairo.ImageList"

That's the global ImageList - yes (with a cCollection working underneath + some "Loader-Functions")

In the end, cCairoSurface-Objects are stored there (under a given Key).
And of course you can store these cCairoSurface-Objects in Arrays, cCollection, cSortedDictionary as well.

You can use the global Cairo.ImageList in "plain Loader-Mode" (with an empty Key) this way:
MyDictionary.Add MyKey, Cairo.ImageList.AddImage("", "c:\temp\someimage.png")

I wonder how I could use it and still be able to maintain some separation.
I guess I could use keys like "Section1Group1ImageGUIDXYX" when adding images but that looks weird

Well, when you put some "dots, or slashes" inbetween - it reads quite nicely (like a path):
"Section1/Group1/ImageGUIDXYX"

Easy to use in "dynamic routines" - where you concat a longer one out of context-strings -
instead of context-objects (sometimes easier to use them, especially in hierarchies to avoid Parent/Child-cycle-refs).

I am not sure how removing images would be done...
I would iterate over the entire image list and remove images and thus changing indexes, right?

Intellisense will show you (when typing Cairo.ImageList.) all kind of Remove-Methods (same as on a cCollection).
And I'd avoid working with indexes here, better to use "speaking Keys".

Olaf

[tmighty2]

One thing I forgot to mention is that in the past I serialized all these imagelists.
I would calculate the hash of all images (each defined by an imageguid) to see if the image list has been serialized, and I can quickly load it by deserializing it or if I have to add the images from a db.
If I would use the Cairo.ImageList, I could no longer do this, I guess, as the images are not grouped, right?

[tmighty2]

When I add a module named modCairo to my project...

Option Explicit

'Just to ensure "global visibility" of the New_c Constructor-
'Variable as well as the "Cairo-Entry-Instance"-Variable
'(throughout our Demoprojects Code-Modules)
Public New_c As New cConstructor

Public Property Get Cairo() As cCairo
Static statCairo As cCairo
If statCairo Is Nothing Then Set statCairo = New_c.Cairo
Set Cairo = statCairo
End Property

then this line fails:

Set WV = New_c.WebView2 'create the instance

How do I solve that?

[Schmidt]

When I add a module named modCairo to my project...

Option Explicit

'Just to ensure "global visibility" of the New_c Constructor-
'Variable as well as the "Cairo-Entry-Instance"-Variable
'(throughout our Demoprojects Code-Modules)
Public New_c As New cConstructor

Public Property Get Cairo() As cCairo
Static statCairo As cCairo
If statCairo Is Nothing Then Set statCairo = New_c.Cairo
Set Cairo = statCairo
End Property

then this line fails:

Set WV = New_c.WebView2 'create the instance

How do I solve that?

I'd leave the "regfree-module" unchanged (having New_c defined as Public Property in the *.bas):

Option Explicit 
Private Declare Function LoadLibraryW Lib "kernel32" (ByVal lpLibFileName As Long) As Long
Private Declare Function GetInstanceEx Lib "DirectCOM" (spFName As Long, spClassName As Long, Optional ByVal UseAlteredSearchPath As Boolean = True) As Object

Private Const DirectComDllRelPath = "\Bin\DirectCOM.dll"
Private Const RCDllRelPath = "\Bin\RC6.dll"

Public Property Get New_c() As cConstructor
  Static st_RC As cConstructor
  If Not st_RC Is Nothing Then Set New_c = st_RC: Exit Property
  
  If App.LogMode Then  'we run compiled - and try to ensure regfree instantiation from \Bin\
     On Error Resume Next
        LoadLibraryW StrPtr(App.Path & DirectComDllRelPath)
        Set st_RC = GetInstanceEx(StrPtr(App.Path & RCDllRelPath), StrPtr("cConstructor"))
        If st_RC Is Nothing Then MsgBox "Couldn't load regfree, will try with a registered version next..."
     On Error GoTo 0
  End If
  If st_RC Is Nothing Then Set st_RC = cGlobal.New_c 'fall back to loading a registered version
  Set New_c = st_RC 
End Property

Public Property Get Cairo() As cCairo
  Static st_CR As cCairo
  If st_CR Is Nothing Then Set st_CR = New_c.Cairo 
  Set Cairo = st_CR
End Property

Despite that, it should work also how you have declared it (Public New_c As New cConstructor) -
but you'd need to ensure a reference to RC6 in your Project of course
(though as said, this "short-variant" will not support "regfree-mode", unless you change to the code-block as posted above).

Olaf

[tmighty2]

I'd leave the "regfree-module" unchanged (having New_c defined as Public Property in the *.bas):

Option Explicit 
Private Declare Function LoadLibraryW Lib "kernel32" (ByVal lpLibFileName As Long) As Long
Private Declare Function GetInstanceEx Lib "DirectCOM" (spFName As Long, spClassName As Long, Optional ByVal UseAlteredSearchPath As Boolean = True) As Object

Private Const DirectComDllRelPath = "\Bin\DirectCOM.dll"
Private Const RCDllRelPath = "\Bin\RC6.dll"

Public Property Get New_c() As cConstructor
  Static st_RC As cConstructor
  If Not st_RC Is Nothing Then Set New_c = st_RC: Exit Property
  
  If App.LogMode Then  'we run compiled - and try to ensure regfree instantiation from \Bin\
     On Error Resume Next
        LoadLibraryW StrPtr(App.Path & DirectComDllRelPath)
        Set st_RC = GetInstanceEx(StrPtr(App.Path & RCDllRelPath), StrPtr("cConstructor"))
        If st_RC Is Nothing Then MsgBox "Couldn't load regfree, will try with a registered version next..."
     On Error GoTo 0
  End If
  If st_RC Is Nothing Then Set st_RC = cGlobal.New_c 'fall back to loading a registered version
  Set New_c = st_RC 
End Property

Public Property Get Cairo() As cCairo
  Static st_CR As cCairo
  If st_CR Is Nothing Then Set st_CR = New_c.Cairo 
  Set Cairo = st_CR
End Property

Despite that, it should work also how you have declared it (Public New_c As New cConstructor) -
but you'd need to ensure a reference to RC6 in your Project of course
(though as said, this "short-variant" will not support "regfree-mode", unless you change to the code-block as posted above).

Olaf

No, it's
Private Const DirectComDllRelPath = "\DirectCOM.dll"
Private Const RCDllRelPath = "\RC6.dll"

Right at my heart!

[tmighty2]

I am using this code:

Option Explicit

'Just to ensure "global visibility" of the New_c Constructor-
'Variable as well as the "Cairo-Entry-Instance"-Variable
'(throughout our Demoprojects Code-Modules)
Public New_c As New cConstructor

Public Property Get Cairo() As cCairo
Static statCairo As cCairo
  If statCairo Is Nothing Then Set statCairo = New_c.Cairo
  Set Cairo = statCairo
End Property

If I use vbRichClient5, it works. 

But using RC6.dll, it throws an error.

I thought the fact that you don't provide vbRichClient anymore means that we should using it.


Private Sub Form_Load()

    Debug.Print Cairo.ImageList.Count'works
    
    Dim lRet&
    lRet = Cairo.ImageList.IndexByKey("abc") 'throws Invalid args error

    If lRet = 0 Then
        Stop
    Else
        Stop
    End If
    
End Sub

Also, I have replaced all my dhRichClient3. stuff with RC6, but it says "Class does not support automation or expected interface":


Dim c As rc6.cConnection
Set c = New rc6.cConnection
c.CreateNewDB

[tmighty2]

I think there is a bug in RC6.Cairo.ImageList:

Dim lRet&
lRet = Cairo.ImageList.IndexByKey(uGUID)

It should return some long value but instead it throws a type mismatch error when the key does not exist.

I am not using On Error Resume Next because too many mistakes happened for this by using this overexcessively in the past so currently I don't have a nice workaround yet.
It would be great it if was possible to get a fix.

[Schmidt]

Something seems wrong with either your registering of the RC6.dll -
or you have more than one RC-reference (beside the RC6-reference) in your project...

In a virginally upstarted, empty VB6-Project (with RC6 as the sole reference),
the following should work correctly: (addressing all the cases you've listed so far).

Option Explicit

Public New_c As New cConstructor

Private Sub Form_Load()
  Debug.Print "SQLite-version: "; New_c.Connection.Version, New_c.Connection(, DBCreateInMemory).FileName
  
  Dim c As cConnection
  Set c = New RC6.cConnection
      c.CreateNewDB
  Debug.Print "SQLite-version: "; c.Version, c.FileName
  
  Cairo.ImageList.AddSurface "abc", Cairo.CreateSurface(1, 1)
  Cairo.ImageList.AddSurface "xyz", Cairo.CreateSurface(1, 1)
  
  Dim idx_abc As Long: idx_abc = Cairo.ImageList.IndexByKey("ABC")
  Dim idx_xyz As Long: idx_xyz = Cairo.ImageList.IndexByKey("XYZ")
  Debug.Print idx_abc, idx_xyz
End Sub

HTH

Olaf

[tmighty2]

And it crashes if I try this:

sGUID = "1/-1/{1BCD3C4B-0628-4030-B024-6103E20F4837}"
lIndex = Cairo.ImageList.IndexByKey(sGUID)

[tmighty2]

Oh, you maybe be right. I will check.

[tmighty2]

Public New_c As New cConstructor

Does that initialize the imagelist? That would explain why it throws an error when I try to access it.

I don't understand New_c As New cConstructor.
Does it globally initalize RC6 for my project?
I did not have that in my project.

Edit: I have added it to my project now, but still when I try to access the empty Cairo.ImageList.IndexByKey, it throws Type Mismatch...

[tmighty2]

Your sample runs fine for me.

However, this does not:

Option Explicit



Public New_c As New cConstructor

Private Sub Form_Load()
  Debug.Print "SQLite-version: "; New_c.Connection.Version, New_c.Connection(, DBCreateInMemory).FileName
  
  Dim lret&
  lret = Cairo.ImageList.IndexByKey("test")
  
  Dim c As cConnection
  Set c = New RC6.cConnection
      c.CreateNewDB
  Debug.Print "SQLite-version: "; c.Version, c.FileName
  
  Cairo.ImageList.AddSurface "abc", Cairo.CreateSurface(1, 1)
  Cairo.ImageList.AddSurface "xyz", Cairo.CreateSurface(1, 1)
  
  Dim idx_abc As Long: idx_abc = Cairo.ImageList.IndexByKey("ABC")
  Dim idx_xyz As Long: idx_xyz = Cairo.ImageList.IndexByKey("XYZ")
  Debug.Print idx_abc, idx_xyz
End Sub

Guess it's really just a bug in IndexByKey.

[jpbro]

Dim lRet&
lRet = Cairo.ImageList.IndexByKey(uGUID)

It should return some long value but instead it throws a type mismatch error when the key does not exist.

What Index should be return for something that doesn't exist? In this case, I guess it's possible that a number <0 could be returned to indicate a missing key, but RC6 raises an error instead (which is more in line with the way other VB6 classes/objects do things).

If you prefer not to raise an error, you can roll your own "IndexByKey" method that returns -1 when a key doesn't exist:

Public Function CairoImageListIndexByKey(ByVal Key As String) As Long
   CairoImageListIndexByKey = -1
   if Cairo.ImageList.Exists(Key) Then CairoImageListIndexByKey = Cairo.ImageList.IndexByKey(Key)
End Function

[Schmidt]

Public New_c As New cConstructor

Does that initialize the imagelist?

...

Edit: I have added it to my project now, but still when I try to access the empty Cairo.ImageList.IndexByKey, it throws Type Mismatch...

Please don't add such " As New cSomeRCClass" lines into any of your RC-Projects...
(instead new RC-ClassInstances should always be derived either from New_c or Cairo)

I've only did it this way in my example in #29, because you had it written exactly this way in your "crash-example" you posted in #27.

And BTW, "crash" for me means, that the IDE-Process "was going down hard",
not a normal COM-error, raised by the library "to tell you something".

As for the New_c (in case you want to re-define the "automatic Constructor-instance" for regfree-mode)...
Please do it like shown in #25 -
or if you want a more elaborate regfree-module, then as jpbro has shown here: https://www.vbforums.com/showthread....ectCOM-amp-RC6

Olaf

[tmighty2]

I think you overlooked that in the sample that you posted I just added that additional line to show you to reproduce the bug.
You can even remove that constructor line:

Option Explicit

Private Sub Form_Load()
  
  Dim lret&
  lret = Cairo.ImageList.IndexByKey("test")
  
End Sub

Try this, it will throw Type Mismatch.

You can also try it any other way of instancing, error is reproducible.

Only if there is at least 1 image in the imagelist, it will work.

[tmighty2]

Public Function CairoImageListIndexByKey(ByVal Key As String) As Long
CairoImageListIndexByKey = -1
if Cairo.ImageList.Exists(Key) Then CairoImageListIndexByKey = Cairo.ImageList.IndexByKey(Key)
End Function

Thanks!

[Schmidt]

Option Explicit

Private Sub Form_Load()
  
  Dim lret&
  lret = Cairo.ImageList.IndexByKey("test")
  
End Sub

Try this, it will throw Type Mismatch.

No, it raises Error 5: "Invalid procedure-call or -argument"
(Same as the VB-Collection BTW, when it cannot find anything under a given key)

Only if there is at least 1 image in the imagelist, it will work.

No,
even if you already have something in the Collection,
the lib will throw the same error 5 at you, when you force it to lookup via a non-existing Key.

There is an .Exists-Method for that (in cCollection and cSortedDictionary as well),
to pre-check whether "a planned access with a certain Key" might fail.

Olaf

[tmighty2]

I can not believe how incredibly good your work is.
I was working with dhRichClient3, vbRichClient4 and various other of your tools.
Yesterday I experienced a crash in a c32bpp list control where some resources were not freed, and I thought that in order to meet the dead line and not risk any crashes, I will remove the cr32bpp image list and also the old tools, and I used just RC6.dll.
I got one sql error telling me that I misuse the SUM() argument, but apart from that, there were no flaws. Providing such backwards compatibility really takes some experience and good planning.
I am really really impressed.
Thank you.

I find myself wanting to use cWebView2 in .NET.
The only thing where .NET / Winforms excells VB6 IMO is tablelayout panels and Unicode and DPI akwardness.
But VB6 is still being used very much I think.

[tmighty2]

Is it possible to serialize / deserialize a VB6 dictionary using vbRichClient?

I am using String and Long

Dim d As New Dictionary

d.Add "SomeString", SomeLong