Update released.
Quite important bugfix when using the RichTextBox control.
Printable View
Update released.
Quite important bugfix when using the RichTextBox control.
Hello Kroll,
How to compile the source code to (for example) comctl.ocx?
Can you give us the guide?
Thank you very much.
i just want to thank you "Krool" your unicode controls really helped me
i wish you luck
Hi Krool,
Thank you very much for your work on the Common Control Replacement.
I am trying out the DataTimePicker and may have stumbled on a bug. This is what I did.
In your VBP demo, I added a DTPicker2 and add the following code:
Private Sub DTPicker2_Change()
MsgBox "change"
End Sub
I ran the project and clicked on DTPicker2 to pop up the Calendar.
When I clicked on any date in the calendar, the MsgBox fired and I closed it.
The MsgBox immediately fired one more time and I closed it again.
It should fire only one time.
When I clicked on the "<" button on the calendar to go to the previous month,
the MsgBox fired and I closed it. Then immediately, it fired repeatedly and
I have to go to Task Manager to kill the VB6 process.
The same happened when I clicked on the ">" button to go the next month.
hello Krool
why when i use unicode controls in my project, the IDE crashes after first run? giving this error "CBool(OldPointer <> NewPointer)"
but in demo sample it doesn't get that error, i cant really find what is the problem..
Update released.
Included the modeless dialogs "Find" and "Replace" in the CommonDialog class.
Unlike the "Find and Replace Common Dialogs" from vbAccelerator these have no issues with the tab keys.
Also mine support multiple modeless dialogs at the same time. But only one per CommonDialog class.
Means that each "single" class can only run one modeless "Find" or "Replace" dialog at the same time.
Sample usage is demonstrated in the RichTextBox Demo.
You mean of how to create a ActiveX Control project?Quote:
Originally Posted by dr_efendi
I have researched this and it seems to be by "design" that the change event (DTN_DATETIMECHANGE) does fire sometimes twice.Quote:
Originally Posted by chosk
And also can cause a loop when for instance showing a MsgBox in the change event as the DTPicker did not receive until then a MouseUp event.
I did a little workaround to fix this and it should be the same behavior now as the original control.
It is impossible to help you without knowing the details of your project.Quote:
Originally Posted by quicken
thank you for your replay krool
i don't know what was the problem, but i replaced controls with updated controls (one of the modules) and my problem solved... thanks again
Hi Krool,
Thank you very much. I appreciate it.
hello krool
I searched the internet and i fund this code :
http://www.Planet-Source-Code.com/vb...59434&lngWId=1
i don't know have you seen this code or not but it would be grate if you do something like this in your unicode controls...
Hi Krool,
I have just replaced 16 ccrpDTP with your DTPicker.ctl and removed ccrpDTP6.ocx and ccrpUCW6.dll. I have also replaced 4 UpDown with your UpDown.ctl and removed ComCT232.ocx. I am moving on to a lot more from ComCtl32.ocx.
One question I like to ask is that to mimick the DTPs from MSComct2 and ccrpDTP that prevent the mouse wheel from changing the date, I have REM out the following in DTPicker.ctl:
Case WM_MOUSEWHEEL from Function WindowProcControl
and
Case WM_MOUSEWHEEL from Function WindowProcCalendar
Is there any side effect that I should be aware of by doing this?
Thanks. I took a look on this and it seems it works via DLL. (ActiveX DLL Project)Quote:
Originally Posted by quicken
And the point is that I don't want this project to have a dependency on any .ocx or .dll.
You can delete the WM_MOUSEWHEEL handler if you want. No side effect.Quote:
Originally Posted by chosk
Hi Krool,
I am moving on to ImageList and encounter "User-defined type not defined" on the following line in ImageList.ctl:
Private PropListImages As ImlListImages
Hi Krool,
Please ignore my previous post. I forgot to add the ".cls" files. Sorry.
I Krool,
May I ask whether you have plan for a replacement of the MSINET.OCX?
Hi Krool,
I am into the last 4 Listviews to replace, having already done many simple ones. For these last 4, I have already got the proper numeric sorting to work. Cell text forecolor should be easy to implement. But I can seem to get alternate ledger color to work. The one I was using utilizes subclassing but it is not working now. Since your controls use a lot of subcalssing, I thought maybe I find some other method. So I search an old source I am familiar with and found it:
http://vbnet.mvps.org/index.html?cod...l/lvledger.htm
I have changed the following in the code:
If lv.View = LvwViewReport Then (from If lv.View = lvwReport Then)
Dim itmX As lvwListItem (from Dim itmX As ListItem)
I REM out he following:
lv.Visible - because this doesn't work after ListView is passed to a Sub (lv as ListView...)
I ran the project, the text in the ListView show up as expected but the alternate ledger color does not work.
I tested with the ListView from MSCOMCTL.OCX and it works.
May I ask is there some thing I need to look at?
Update released.
This works now.Quote:
Originally Posted by chosk
There was a problem that the '.Image' property of the PictureBox was directly passed to the Picture property of the ListView. But this case is now solved in the update.Quote:
Originally Posted by chosk
Keep in mind that the Picture property requires comctl32.dll version 6.0 or higher in order to work.
But you could just use for this case the 'ItemBkColor' event. (?)
This sample will make a red background color of every second ListItem.
Code:Private Sub ListView1_ItemBkColor(ByVal Item As LvwListItem, ColorRef As Long)
If Item.Index Mod 2 Then ColorRef = vbRed
End Sub
Hi Krool,
Thanks for the update.
.Visible now works after ListView is passed into a Sub.
Silly me. Didn't realise ItemBkColor exists in your ListView ctl. Been too used to MS's that I did not think of this. This makes it so much easier. Now I can even implement Alternate Ledger Color on ListViews where I could not. This is fantastic.
Now I am left to find ways to do stuff I did with msinet.ocx and I should be free of com registration problem that Win8 is causing a lot of pain.
I just like to update that I have replaced the use of msinet.ocx with MSXML. It is pre-installed in WinXP SP3 and later (up to Win8.1) and can be installed in WinXP SP2 with Windows Installer. The important thing for me is it has the option to use Username and Password which is what I need.
http://msdn.microsoft.com/en-us/data/bb291077.aspx
The only controls I have not replaced are those "basic" ones that come pre-installed in VB6 - label, command button, frame, check, option, combo, text. Am I right to understand that these do not require "addition" dependencies outside of the VB6 runtime and the few that are Windows system files?
Yes, you are right. No "addition" dependencies. There are included in the msvbvm60.dll.Quote:
Originally Posted by chosk
Thanks Krool.
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.
Update released.
Indeed there was a updating bug, which is fixed now. ThanksQuote:
Originally Posted by chosk
Hi Krool,
Sorry! - another bug but easy to reproduce.
Tr is a unicode string containing Hebrew. Text1 is a Textw control.Code:Tr = StrConv(Tr, vbFromUnicode)
Text1.Text = Tr
If the date / time format is english...
Attachment 110983
The text displays correctly....
Attachment 110985
But if the date /time format is Hebrew...
Attachment 110987
The text is corrupt....
Attachment 110989
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.
Why do you use StrConv? That might be the reason why you loose the unicode chars.Quote:
Originally Posted by JohnTurnbull
To convert it to chars from unicode! Tr is retrieved from a file where it was previously saved using StrConv(Tr, vbUnicode)Quote:
Why do you use StrConv?
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.
Create a form
add a textboxw
add a command button
Add code
Click command1 with English date/time - No ProblemCode: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 Hebrew date/time - Rubbish
When to use StrConv...
StrConv is the Uni-to-ANSI (or ANSI-to-Uni) Helper-Function of VB6.Quote:
Originally Posted by JohnTurnbull
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).
As just said, this is absolutely wrong, since StrConv doesn't work lossless as a Text-Encoder/Decoder,Quote:
Originally Posted by JohnTurnbull
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).
Maybe, but with your Unicode-Handling and usage of the Strconv-Function there are definitely problems you will encounter,Quote:
Originally Posted by JohnTurnbull
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?
Now put that string directly (without any StrConv-functions) into the Unicode-Textbox.Code: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
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
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.
Then StrConv shouldn't be necessary?Quote:
Originally Posted by 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.
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.
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.
The Windows-Clipboard does support UTF-16 (in Write- and Read-Direction), when CF_UNICODETEXT = 13 is used...Quote:
Originally Posted by JohnTurnbull
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
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.Quote:
Originally Posted by Schmidt
Edit: Scratch this... this works only with the OLE DataObject in UserControls.
So it is necessary to use the Clipboard APIs in this case.
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
Is there any way to tell if a user has selected "Right to left reading order" in a textboxW ?
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?
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
Check for the extended style WS_EX_RTLREADING.Quote:
Originally Posted by JohnTurnbull
Thank you!Quote:
Originally Posted by Krool
John T
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)
Attachment 111039
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.
You shouldn't do that. (Opening and closing the .ctl)Quote:
Originally Posted by Romeo91
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. :eek2:
Or just be careful and don't open the .ctl.
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.
Hi 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.Quote:
Originally Posted by 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.
You have to use a manifest in order to use comctl32 version 6. Then you have not to use a custom arrow anymore.Quote:
Originally Posted by 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.)
You could use the Color Palette window instead:Quote:
Originally Posted by chosk
I mean: how to compile your codes to be one activex control,Quote:
Originally Posted by Krool
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.
Obselete
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
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.
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
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.Quote:
Originally Posted by Schmidt
Duplicate post removed.
No, a binary Component-Technology which is class-based and offers self-describing InterfacesQuote:
Originally Posted by chosk
(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).
Yes, Krools-Tools offered a way out of the breakage of interfaces (not COM itself) a thing which wasQuote:
Originally Posted by chosk
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
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.Quote:
Originally Posted by Schmidt
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.
Obselete
Obselete