CommonControls (Replacement of the MS common controls)

[chosk]

Hi Krool,

I have a statusbar panel that show time. When leave the windows in the same size, the time update over-write and gets garbled. Meaning time is 02:37, when it gets to 02:38, the 8 over-write the 7. When it gets to 02:40, the 4 over-write the 3. Resizing the windows will clear the garble.

No sure whether the date have the same problem. Did not have a chance to wait so long.

It will be good also if can show AM and PM.

[Krool]

Update released.

I have a statusbar panel that show time. When leave the windows in the same size, the time update over-write and gets garbled. Meaning time is 02:37, when it gets to 02:38, the 8 over-write the 7. When it gets to 02:40, the 4 over-write the 3. Resizing the windows will clear the garble.

Indeed there was a updating bug, which is fixed now. Thanks

[JohnTurnbull]

Hi Krool,

Sorry! - another bug but easy to reproduce.

Tr = StrConv(Tr, vbFromUnicode)
Text1.Text = Tr

Tr is a unicode string containing Hebrew. Text1 is a Textw control.

If the date / time format is english...



The text displays correctly....



But if the date /time format is Hebrew...



The text is corrupt....



The same fault if Date /time is set to Russian, Greek and several other languages.

The fault only occurs with Hebrew and the only affecting factor is Date/Time format

John Turnbull
M8 Software Support
Saturday 22nd February
10.35am UK time.

[Krool]

Sorry! - another bug but easy to reproduce.

Tr = StrConv(Tr, vbFromUnicode)
Text1.Text = Tr

Tr is a unicode string containing Hebrew. Text1 is a Textw control.

Why do you use StrConv? That might be the reason why you loose the unicode chars.

[JohnTurnbull]

Why do you use StrConv?

To convert it to chars from unicode! Tr is retrieved from a file where it was previously saved using StrConv(Tr, vbUnicode)

There is no problem with my code! It works perfectly in English, Russian, Chinese and Arabic. It only fails in Hebrew and then only when when The Windows date format is Hebrew, Russian or Greek. The screen shots in my last post are genuine. When the date format is English, the textw displays correctly. When the date/time format is Hebrew, it does not. There are no other factors affecting the problem.

[JohnTurnbull]

Create a form
add a textboxw
add a command button

Add code

Option Explicit
Dim Tr$

Private Sub Command1_Click()
TextBoxW1.Text = StrConv(Tr, vbFromUnicode)
End Sub

Private Sub Form_Load()
Tr = "հиԷѰ꼸  Ðµê  Ù°Ù¸  |   бܹԶÙÚ¸,   Ѽ°Û¸Ü- ܰѸ½Ñ°Ú¸,   ռѰ۸Ü- à·ä°éÁ°Ú¸,   ռѰ۸Ü- ްйӶ½Ú¸.   Õ°Ô¸ÙÕ¼  Ô·Ó¼°Ñ¸è´ÙÝ  Ըеܼ¶Ô,   вéÁ¶è  |   и½à¹Û´Ù   "
End Sub

Click command1 with English date/time - No Problem
Click command1 with Hebrew date/time - Rubbish

[Schmidt]

When to use StrConv...

To convert it to chars from unicode!

StrConv is the Uni-to-ANSI (or ANSI-to-Uni) Helper-Function of VB6.

And with: StrConv(Tr, vbFromUnicode)
you definitely perform a (potentially, and locale-dependent) *lossy* conversion from Unicode-Content to ANSI.

Krool is absolutely right.

As soon as true Unicode-Controls are in use, StrConv is not needed at all anymore
(aside from converting old Textfiles which were stored in ANSI-format in a given Locale,
to Unicode-content, using the right (matching) LCID as the second Parameter of the StrConv-function).

StrConv is for *legacy* stuff, for TextData stored in an old non-unicode-format.

As soon as you have true Unicode-Content in your VB-Strings, you can pass them
directly into the W-capable Controls - and to persist them, you store their contents
either in unicode-capable Databases, or in Textfiles in UTF-16-Format (directly possible
in VB over an intermediate ByteArray) - or in UTF-8 (possible per WideCharToMultiByte-API -
and definitely *not* per StrConv-Function).

Tr is retrieved from a file where it was previously saved using StrConv(Tr, vbUnicode)

As just said, this is absolutely wrong, since StrConv doesn't work lossless as a Text-Encoder/Decoder,
when changes in the User-locale are involved (exactly the thing you're provocing with your change
between Hebrew and English in the appropriate Dialogue).

There is no problem with my code!

Maybe, but with your Unicode-Handling and usage of the Strconv-Function there are definitely problems you will encounter,
as soon as you provoce different locale-settings.

Let's maybe start-up with a correctly formatted Unicode-String, set-up per ChrW-construct.
(and let's not ask for the moment, from what datafile it was retrieved ... wherever it came from, it is correct and now sitting in a VB-String, OK?

Option Explicit

Dim UniHeb As String

Private Sub Form_Load()
  'different Uni-ChrW-Test-Sets on Dr-Unicodes site: http://www.cyberactivex.com/unicodetutorialvb.htm
  UniHeb = "HEB: " & ChrW(&H5D1) & ChrW(&H5E8) & ChrW(&H5D5) & ChrW(&H5DB) & ChrW(&H5D9) & ChrW(&H5DD) & _
               " " & ChrW(&H5D4) & ChrW(&H5D1) & ChrW(&H5D0) & ChrW(&H5D9) & ChrW(&H5DD)
End Sub

Now put that string directly (without any StrConv-functions) into the Unicode-Textbox.

I'm pretty sure that the TextBoxW1 will *always* render the correct and same result,
no matter what you change in the Dialogue you mentioned.

What now remains is, to talk about correct persisting and retrieval of this
String-content (either as UTF-16-file of as a somewhat more efficient UTF8-File).

Olaf

[JohnTurnbull]

Hi Olaf,

That's all very interesting. Unfortunately, the source of Tr$ is format 13 from the Windows clipboard which is pure unicode. The Windows clipboard does not provide a UTF 8 or UTF 16 format.

John Turnbull
M8 Software Support
Sunday 23rd February
9.13am UK time.

[Krool]

That's all very interesting. Unfortunately, the source of Tr$ is format 13 from the Windows clipboard which is pure unicode. The Windows clipboard does not provide a UTF 8 or UTF 16 format.

Then StrConv shouldn't be necessary?

[JohnTurnbull]

Hi Krool,

You're right of course. The reason for the conversion is that before I show it in the textboxw, I have to strip out leading carriage returns and trunctate it to also show in a label. This is much easier to do after scrconv.

Anyway, looks like it's my problem not yours! Just very strange that it only happens with Hebrew. I guess the answer is to keep two copies, the original unicode for showing in textboxw and the strconv for everything else.

Sorry to trouble you.

John Turnbull
M8 Software Support
Sunday 23rd February
10.00am UK time.

[Krool]

Yes. StrConv can cause some troubles on certain settings.

For example on japanese system there are also problems.
The reason is due to the fact that even the ANSI strings on japanese systems are also 2-byte and not 1-byte. So when using StrConv the 2nd byte is lost.

[JohnTurnbull]

Thanks to Schmidt and Krool for all help. One last piece of advice please.

Before rewriting (which is a huge job) I tried adding my LCID (English United Kingdom) to all StrConv functions and that has cleared the problem! I am now testing through all other languages. If you can think of a situation where this might not work, please let me know so I can test it out.

John Turnbull
M8 Software Support
Sunday 23rd February
11.22am UK time.

[Schmidt]

Unfortunately, the source of Tr$ is format 13 from the Windows clipboard which is pure unicode. The Windows clipboard does not provide a UTF 8 or UTF 16 format.

The Windows-Clipboard does support UTF-16 (in Write- and Read-Direction), when CF_UNICODETEXT = 13 is used...

Unfortunately the VB.Clipboard does not support this Format-Constant (only the ANSI-Constant CF_Text = 1 is supported).

So, to place and retrieve VBs internal W-Strings directly on and from the clipboard, you will need (in the same way as with unicode-capable Controls) a Clipboard-Class which supports Unicode (there's stuff in the CodeBank or also on PSC for that, but vbRichClient also has a cUniClipBoard-Class).

So, with Unicode-capable Controls and an Unicode-capable Clipboard you have some helpers which will allow you "to ban" VBs ANSI-conversion-functions entirely from your App...
You can place and retrieve VB-Strings directly (to and from Controls or an UnicodeClipBoard-Class) and thus "work entirely in W-Space".

As said, you only need to take care, when you pull String-Content "from elsewhere" (e.g. the FileSystem or the Web) into that "W-Space" - or when you want to "export" String-Content from your "W-Space" into the FilesSystem or into "Web-Formats" (as e.g. HTML or XML).

When you export into the FileSystem, then DBs are usually safe, because the ADO-layer already is "W-capable" - as well as the OleDB-driver-layers - and finally the DB-Backends too.
Plain-Textfiles should be written into with either UTF-16 or UTF-8 (and their appropriate BOMs to make retrieval easier for others, when such a "Hint" is contained in the first Bytes of a plain-text-file) - and for putting out VBs WStrings into XML or HTML, there's appropriate Header-Tags for either UTF-16 or UTF-8 as well...

Glad to hear, that you were able to fix your current issues by forcing the StrConv-functions to act "under guidance" of an explicitely given LCID now - but that's only a temporary fix (in my understanding) on your way to a true unicode-capable Application, since you are essentially still dealing with ANSI in your App.

If you're still unsure about things I just wrote above, then maybe post a new Thread for that in the normal Forum - maybe with a concrete problem (with concrete Text-Content) - but if you do so, try to describe exactly, where the String-Content in question really had its very origin - and what potential conversions this String-Content may already have undergone on its way into your VB.String-Variable...

To conclude again - try to ensure a "clean W-Space" in your unicode-capable App.
Working "within W-Space" (normal VB-Strings as transport-containers) is absolutely easy, when you use Unicode-capable Controls and an Unicode-capable Clipboard - you can pass String-Content directly then (without StrConv).

The only thing you need to take care of is, when the "borders to your W-Space" are passed (when you pull from Web-or XML-content or from the Filesystem).

Olaf

[Krool]

Unfortunately the VB.Clipboard does not support this Format-Constant (only the ANSI-Constant CF_Text = 1 is supported).

So, to place and retrieve VBs internal W-Strings directly on and from the clipboard, you will need (in the same way as with unicode-capable Controls) a Clipboard-Class which supports Unicode (there's stuff in the CodeBank or also on PSC for that, but vbRichClient also has a cUniClipBoard-Class).

I think there is no problem with VBs Clipboard function. Just pass CF_UNICODETEXT into Clipboard.GetFormat()/GetData(). It will return a byte array (Unicode) which can be casted to a string.

Edit: Scratch this... this works only with the OLE DataObject in UserControls.
So it is necessary to use the Clipboard APIs in this case.

[JohnTurnbull]

Hi Folks,

We're going off at a tangent here. I don't have a problem with the clipboard! I save and replace all clipboard formats using the API.

I only have a problem displaying a unicode clip to the user. To do that, I take a small extract from the clipboard data and save it as a separate file to the clip itself. This file contains one of the following - If unicode format 13 is present,the first 1000 bytes from that. If not present, the first 1000 bytes from format 1 (plain text) or a thumbnail if the clip is graphic.

This small file is necessary because the preview has to load and display a clip as fast as the user moves his mouse over the grid of clip names. The preview file is further complicated by the fact that it also contains a long representing the color to display the clip name and a smaller, 50 byte extract to display as the clip name itself. That extract has to have any leading spaces or carriage returns removed. It's length is also adjusted by length of text depending on font, as it has to be displayed in a grid of LabelWs. Both the name and preview texts are either trimmed to length if the real clip is longer or padded with spaces if shorter so that they can be saved to the file with fixed lengths for easy retrieval.

The entire system was developed without unicode support about fifteen years ago. In the last six months I have replaced textboxes and labels with Krool's controls. By using StrConv on the extractions, I can keep all the existing text processing intact. OK, it's perfectly possible to trim, pad and process unicode strings directly but that would be a massive re-write. (The find and replace to add the LCID to strconv resulted in over 100 changes!) So, obviously, If adding LCID to the strconvs works, I am going to stick with it..... So far, no problems.

John T

[JohnTurnbull]

Is there any way to tell if a user has selected "Right to left reading order" in a textboxW ?

[Schatn]

Hello Krool,

I really love the work you've done here! Been looking for something like this for some time now

I know you intended this to be integrated into the programs so one wouldn't need any dependencies, but still, is there any way you'll be releasing this an OCX version?

[Romeo91]

Friends, I was not the first time I've heard the request and questions regarding ocx-version. For what it is you what their applications for drag additional files? And yet, and register them in the system. Here the project with a fully open source (also very convenient directory structure of the project), and all this without any problems embedded in the code of any of its projects. Adding common modules (bas) and classes (cls), necessary for correct operation, and add the dates you control (ctl), every control lie in a separate folder.
I do not know about you, but I always disliked ocx-controls

[Krool]

Is there any way to tell if a user has selected "Right to left reading order" in a textboxW ?

Check for the extended style WS_EX_RTLREADING.

[JohnTurnbull]

Check for the extended style WS_EX_RTLREADING.

Thank you!

John T

[Romeo91]

Good day .
Very often when I look at the code of your project ( the code of the project do not change ), I get an error that has previously been mentioned repeatedly
Debug.Assert CBool ​​(OldPointer <> NewPointer)


This occurs when the main form is opened and you open any control. And when you exit the control ( push X ) I get an error .

Ide protection enabled you default .
I understand that the control is updated , and the project is redrawn from scratch, but why there is an error , elsi nothing changed . As with many other projects of this did not occur. Maybe something is wrong in sabsclassing ?
One can get around this ?

Repeatedly pressing F5, can lead to performance of the project, or a hang or error.
When you close the project, VB reports a change of the main form and offers to save it. But does not save, and shows the same error.

[Krool]

I get an error that has previously been mentioned repeatedly
Debug.Assert CBool ​​(OldPointer <> NewPointer)


This occurs when the main form is opened and you open any control. And when you exit the control ( push X ) I get an error .

You shouldn't do that. (Opening and closing the .ctl)
Reason is because of subclassing and the .ctl gets "interrupted" when you open the .ctl while it is subclassed.

An solution is to make an .OCX out of the project. Then the .ctl are not "changeable" anymore and thus do not crash.

Or just be careful and don't open the .ctl.

[chosk]

Hi Krool,

I see in your listview example where the sort arrow is applied. I can see in your sample how you put the sort arrow in "EnumColumn.IconOnRight = True". In non-Visual Theme mode, I am getting a big arrow in the ColumnHeader even though I made the arrows 16x16 in the ImageList. Your sample show a small arrow. No problem when running in Visual theme as I think Windows may handle that - small arrow at centre top of columnheader.

I have tried looking but still must be missing a setting or two somewhere and I can't seem to find out where. Appreciate if you could give me a pointer.

Thanks.

[chosk]

Hi Krool,

I just made my arrow 8x8 and this is much closer to yours. I think this is the trick?

[Krool]

I just made my arrow 8x8 and this is much closer to yours. I think this is the trick?

Yes. Keep in mind that arrow image (custom one via image list) is needed only when version of comctl32.dll is 5 or lower. It is not dependent on whether visual styles are enabled or not.

[chosk]

Hi Krool,

Thanks for the confirmation.

And yes. Indeed my comctl32.dll is version 5.82.7601.17514 in my install of Win7 x86. I was looking at the ComCtlsSupportLevel function and must have gotten a "0" back (< ver 6) since the arrows were used.

Thanks.

[Krool]

And yes. Indeed my comctl32.dll is version 5.82.7601.17514 in my install of Win7 x86. I was looking at the ComCtlsSupportLevel function and must have gotten a "0" back (< ver 6) since the arrows were used.

Thanks.

You have to use a manifest in order to use comctl32 version 6. Then you have not to use a custom arrow anymore.

[chosk]

I do use a manifest in the res to use ver 6 so that the compiled exe will run with "new/modern look" theme in XP and later. When I run the project in the VB6 IDE, the project GUI look like Win2000 and earlier, therefore the custom arrow.

(I know I can use a manifest for VB6 IDE, but the color palette in properties is one of the thing that will not work and the IDE may be slower.)

[Bonnie West]

(I know I can use a manifest for VB6 IDE, but the color palette in properties is one of the thing that will not work and the IDE may be slower.)

You could use the Color Palette window instead:

[dr_efendi]

You mean of how to create a ActiveX Control project?

I mean: how to compile your codes to be one activex control,
for example comctl.ocx.
Because I could not change your codes target to be activex control.
I wish I can create project will refer to the ocx (of your codes), not with including your file codes.
I hope you understand what I mean.
Thank you.

[Krool]

Obselete

[Schmidt]

Thanks for the OCX-version - also managed an ocx-compile (about half a year ago, trying to "promote" it a bit in the german forum on ActiveVB):
http://foren.activevb.de/archiv/vb-c...g-mit-Windows/

And whilst it worked for me at that time on both - my Win7-machine and within a XP-VM, there seemed to be no success on the other users system.
"Error whilst loading a Dll" (Fehler beim Laden einer Dll).

Funnywise I now can reproduce that exact error (as reported in the german forum-thread) here on a newer Win8-Notebook (running VB6/SP6 - reproducable with both versions - my older compile - and yours is not starting up as well - even in an otherwise empty, virginal VB6-StdExe-project, as soon as you want to check-out the compiled OCXes over the Component-Dialogue).

Would be great, if that could be resolved somehow, because having a binary COMponent is (IMO) always preferrable - especially with such large code-bases - and as soon as the COMponent-Classes have reached (more or less) stable interfaces. There's just easier and faster coding in the IDE - more stability (since the SubClassing-stuff now runs compiled in its own Binary) etc...

Olaf

[chosk]

The reason I use these non-OCX ctls is maybe the same reason you now having on Win8. My program setup created with InstallShield was not installing properly on Win8 although it had done so reliably on Win7 and earlier. After running the setup, on first launch, would get an "Application-defined or object-defined error". I know this to be related to ActiveX and OCX not properly registered into the Windows Registry. No matter how I looked at the InstallShield setup, I am unable to find the problem. I even retained the use of having the string "setup" in the setup file name (example MyProgsetup.exe) as recommended by Microsoft and it worked to overcome registration problem in Vista, but not Win8. So I went searching for non-OCX replacement and I am glad I found this.

I read through this thread and I see some requests to make this an OCX but from my reason, I would rather prefer it the way it is - just ctls and compiled into the same program exe. Now I just copy the exe into any other Windows PC, even Win8, and it just run. The VB6 runtime and other system required files are already pre-installed into Windows and I can comfortably forget about the dreaded ActiveX/OCX registration in Win8.

[Schmidt]

Potential problems with the deployment of OCXes (as well as their weird OCA-caching-mechanisms and their complicated siting-calls) is one reason I prefer ActiveX-Dlls over OCXes.

Though I'm still deeply convinced about the advantages of COM-Components vs. direct usage of huge Code-Bases in a Project (especially when those involve SubClassing).

For me it's quite important to have fast Startup-Times and a reliable debugging of the current ("clean, small and unrelated") Project-Sources I work on.

That's the Background which would make an OCX-version of Krools Sources desirable.

But preferences differ, that's for sure - and the "All-in-one-Exe"-goal seems to be some kind of "obsession" in the VBClassic-community (for no apparent reason).

Olaf

[chosk]

But preferences differ, that's for sure - and the "All-in-one-Exe"-goal seems to be some kind of "obsession" in the VBClassic-community (for no apparent reason).

It is not an obsession, it is survival. With Windows 8, removing ActiveX and OCX is a necessity as many will find out in time. I accepted the shock, the disappointment, found a solution and move on. I can't express how much I want to thank Krool to make this possible.

[chosk]

Duplicate post removed.

[Schmidt]

It is not an obsession, it is survival. With Windows 8, removing ActiveX and OCX is a necessity as many will find out in time.

No, a binary Component-Technology which is class-based and offers self-describing Interfaces
(in our case this is COM and TypeLibs) is a Plus - and this technology is definitely *not*
broken in Win 8 and Win 8.1.

COMponents are (in my opinion) far under-used in the VBClassic-community - hence my comment about
the "obsession" to put everything but the kitchen-sink (as code-modules) into one Mega-Std-Exe-Project.
That's (especially since techniques like RegFree-COM are available for years now) just "not how it's done".

When we look at things from an engineering-perspective, then you will have (in case complexity increases)
to split-up into more managable parts, which - when done right - are even reusable in similar scenarios
or the next project with a simple mouse-click (a check-in over the Components- or References-Dialogue).

I accepted the shock, the disappointment, found a solution and move on.
I can't express how much I want to thank Krool to make this possible.

Yes, Krools-Tools offered a way out of the breakage of interfaces (not COM itself) a thing which was
caused by the *vendor* (MS), and happening the second time already (after the ADO-interface-trouble) -
that's (for such a big vendor with a huge set of test-cases and -tools) either plain stupid - or was done
deliberately, just to spread a little more FUD among the members of the VB6/VBA community...

In either case COM (the Component-Technology) was never broken at all.
MSHFlex.ocx, MSWinsock.ocx, scrrun.dll, the MS-XML-components ... as well as ones own,
VB6-generated COMponents, all work as before also on Win8.

If a COMponent doesn't properly install on a given OS, blame the people who are responsible
for this Component (and its Typelib-Interfaces or 2nd-level-dependencies) - don't blame the
Component-Technology itself - so far MS refrained from "fiddeling" with *that* can of worms
(since this would break also their own Office-products and huge parts of the industry).


Olaf

[chosk]

No, a binary Component-Technology which is class-based and offers self-describing Interfaces
(in our case this is COM and TypeLibs) is a Plus - and this technology is definitely *not*
broken in Win 8 and Win 8.1.
...
...
If a COMponent doesn't properly install on a given OS, blame the people who are responsible
for this Component (and its Typelib-Interfaces or 2nd-level-dependencies) - don't blame the
Component-Technology itself - so far MS refrained from "fiddeling" with *that* can of worms
(since this would break also their own Office-products and huge parts of the industry).

Nah, I never say COM was broken in Win8/8.1. Never did. I just say InstallShield (MSI) setup have problem installing COM components in Win8/8.1 when it never had such problem with Win7 and earlier.

I was only trying to share my experience with you since you did mentioned you had problem installing (your own compiled of Krool's into OCX 6 about half a year ago and now) in Win8. I am sorry that I even tried to share.

Blaming anyone (others or myself) for COM components not properly installed is no use. Blaming will not make COM components install properly. Only a solution can. I have been looking for a solution for many months and I found it here. Thanks for your side of opinion but it really doesn't help solve the problem on Win8.

I don't wish to dwell on it. You can have the last words if you want. I am moving on. Thanks anyway.

[Krool]

Obselete

[Krool]

Obselete