|
-
Oct 6th, 2016, 11:48 PM
#1161
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by GaryW
Need to get a copy of a VB6.exe.manifest to use updated comctl32.dll
http://www.vbforums.com/showthread.p...ues&highlight=
-
Oct 11th, 2016, 01:27 PM
#1162
Fanatic Member
Re: CommonControls (Replacement of the MS common controls)
There is a problem with the CommonDialog.
For ShowSave, it doesn't return the entered filename + extension.
The original delivers the extension.
Code:
Dim CD As CommonDialog
Dim TheFile As String
'--------------------------------------------------
Set CD = New CommonDialog
With CD
.Flags = CdlOFNOverwritePrompt Or CdlOFNHideReadOnly Or CdlOFNExplorer
.Filter = "?INI files" & "(*.ini)|*.ini|" & "?All files" & " (*.*)|*.*|"
.DialogTitle = "?Export configuration"
.InitDir = GS.Inifolder
.ShowSave
TheFile = .FileName
End With
Set CD = Nothing
MsgBox TheFile
End Sub
Example:
In the dialog, I enter 'BLA'.
The original returns 'C:\SomePath\BLA.INI'.
The kroolish returns 'C:\SomePath\BLA'.
Do I miss something?
Karl
-
Oct 11th, 2016, 04:17 PM
#1163
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by Karl77
Do I miss something?
The DefaultExt property.
-
Oct 11th, 2016, 11:24 PM
#1164
Addicted Member
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by GaryW
Need to get a copy of a VB6.exe.manifest to use updated comctl32.dll
Can you enlight me on this ?? wich updated comctl32.dll ??
I'm using v6.1.7601.18837, wich techniquely is the last that I know of. and I don't use manifest.
-
Oct 11th, 2016, 11:27 PM
#1165
Addicted Member
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by Krool
Hi Krool, I looked at your post on this... I don't understand why you're using this. I'm on Win7x64 I don't have any problem with UAC (of course you need to set up your Shortcut link the proper way) What would be my gain to use Manifest ? I also tried to follow the method you described to see if any difference and Ressource Hacker refused to insert the res file. Did I miss something ?
-
Oct 12th, 2016, 02:37 AM
#1166
Fanatic Member
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by Krool
The DefaultExt property.
Thanks.
I never had to use it, the original seems to make it automatic.
Also the other replacement I formerly used.
From what I see here, the 'lpstrDefExt' only must not be empty to achieve this.
It wouldn't hurt if your controls would do the same.
But not very important for sure.
I can send you the code of the other replacement if wanted.
Karl
-
Oct 12th, 2016, 10:25 AM
#1167
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by Karl77
It wouldn't hurt if your controls would do the same.
But not very important for sure.
I can send you the code of the other replacement if wanted.
I agree that behavior should be the same.
Please share the other replacement.
-
Oct 12th, 2016, 01:14 PM
#1168
Re: CommonControls (Replacement of the MS common controls)
Update released.
 Originally Posted by Karl77
From what I see here, the 'lpstrDefExt' only must not be empty to achieve this.
That was exactly the point. Thanks
I just needed to add the following code to get the expected behavior: (DefaultExt is an extra buffer)
Code:
If PropDefaultExt = vbNullString Then DefaultExt = vbNullChar Else DefaultExt = PropDefaultExt
.lpstrDefExt = StrPtr(DefaultExt)
Because when 'lpstrDefExt' is NULL (according to MSDN), no extension is appended at all.
Therefore in our case 'lpstrDefExt' should be never NULL, because we want an extension appended.
The DefaultExt property therefore only has effect when the Filter was *.*
The only scenario where no extension will be appended is when the selected filter was *.* and the DefaultExt is not set. (=vbNullChar)
Last edited by Krool; Oct 12th, 2016 at 01:23 PM.
-
Oct 21st, 2016, 11:04 AM
#1169
Lively Member
Re: CommonControls (Replacement of the MS common controls)
This is spectacular work...wow, thank you. However, I'm having an issue with the RichTextBox playing nicely with the Find dialog control.
When I search for a word using the Find dialog box, it is not getting highlighted within the RichTextBox. However, I know it is finding it, because once I close the Find/Replace dialog box, the RichTextBox suddenly gets the focus and the proper "found" word becomes highlighted. What am I overlooking?
Also, is there a function that allows "Replace" as well or is it only restricted to the "FIND" property?
-
Oct 21st, 2016, 01:28 PM
#1170
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by swambast
This is spectacular work...wow, thank you. However, I'm having an issue with the RichTextBox playing nicely with the Find dialog control.
When I search for a word using the Find dialog box, it is not getting highlighted within the RichTextBox. However, I know it is finding it, because once I close the Find/Replace dialog box, the RichTextBox suddenly gets the focus and the proper "found" word becomes highlighted. What am I overlooking?
Also, is there a function that allows "Replace" as well or is it only restricted to the "FIND" property?
Look at the Demo. There you find a working find dialog. For the replace is actually the same. Use the Find method and then set the SelText property to your replace text.
-
Oct 21st, 2016, 05:27 PM
#1171
Lively Member
Re: CommonControls (Replacement of the MS common controls)
Krool, yes I tried to reproduce that and that is the exact code bank I was using from the demo, but still same issue. Part of resolution that helped was setting custom form to modeless but now there's still other errors on form load, and sometimes the RTB just grays out or won't load (not to mention all the other build dependencies as well). So honestly Krool, despite my excitement and absolute interest in this, this is beyond me and I've simply spent far too much time trying to get everything to work...feel like I'm putting together a jigsaw puzzle here constantly with missing pieces.
I'm going back to the standard controls now despite a few more .ocx and loss of visual themes - they just tend to work more straight forward and I have supporting code that covers the unicode issues anyway. I wanted to say thanks for your efforts on providing us with another option though!
-
Oct 22nd, 2016, 01:53 AM
#1172
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by swambast
Krool, yes I tried to reproduce that and that is the exact code bank I was using from the demo, but still same issue. Part of resolution that helped was setting custom form to modeless but now there's still other errors on form load, and sometimes the RTB just grays out or won't load (not to mention all the other build dependencies as well). So honestly Krool, despite my excitement and absolute interest in this, this is beyond me and I've simply spent far too much time trying to get everything to work...feel like I'm putting together a jigsaw puzzle here constantly with missing pieces.
I'm going back to the standard controls now despite a few more .ocx and loss of visual themes - they just tend to work more straight forward and I have supporting code that covers the unicode issues anyway. I wanted to say thanks for your efforts on providing us with another option though! 
I bet your issues can be solved.
However, you might try the OCX version. (please pm me)
-
Oct 24th, 2016, 08:55 AM
#1173
New Member
Re: CommonControls (Replacement of the MS common controls)
Hello Krool, I have downloaded and used "VBCCR13.OCX" as a replacement for "MSCOMCTL.OCX" on July 13th 2016. I had done this because of problems with that reference in my Access applications since August 2012. This problem occurred after a Windows Update from time to time. Generally, a workaround could be found in registering an older version, but lately this failed to work on certain PC's at a client site. The "VBCCR13.OCX" replacement worked fine for some time, but the client has now some new PC's that have problems with that replacement. The "MSCOMCTL.OCX" reference works fine for those PC's now. So this is confusing me of course.
I can't dowload new versions of "VBCCR13.OCX", I would need to send you a pm. I just registered as a new member but I can't send a private message so far.
Of course, would I solve my specific problem with a new version, or is this some recurring nasty registry problem that I'm suffering from?
Thanks in advance for your opinion.
-
Oct 24th, 2016, 04:25 PM
#1174
New Member
Re: CommonControls (Replacement of the MS common controls)
Hello Krool,
how can I remove focus rect?
Thanks.
-
Oct 25th, 2016, 03:38 PM
#1175
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by lhartono
how can I remove focus rect?
Find and remove all kinds of WM_CHANGEUISTATE messages.
Code:
SendMessage hWnd, WM_CHANGEUISTATE, MakeDWord(UIS_CLEAR, UISF_HIDEFOCUS Or UISF_HIDEACCEL), ByVal 0&
 Originally Posted by martin.matten
would I solve my specific problem with a new version, or is this some recurring nasty registry problem that I'm suffering from?
A new version would certainly change nothing in that regard. I think it is some registry problem on your PC.
-
Oct 26th, 2016, 08:49 AM
#1176
New Member
Re: CommonControls (Replacement of the MS common controls)
OK Krool, thanks for your opinion.
In the meantime I have made 2 runtime versions for my application. So far, if the version MSCOMCTL doesn't work, the VBCCR13 does, or vice versa. Let's hope that this workaround will stand until we have a clear view on the registry problem behind...
-
Oct 26th, 2016, 05:48 PM
#1177
Hyperactive Member
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by martin.matten
OK Krool, thanks for your opinion.
In the meantime I have made 2 runtime versions for my application. So far, if the version MSCOMCTL doesn't work, the VBCCR13 does, or vice versa. Let's hope that this workaround will stand until we have a clear view on the registry problem behind...
If you use VBCCR13 with the side-by-side resource provided, you will never encounter any problem caused by registry in the user computer. Your application will always run no matter what problem there may be with the registry.
The only consideration is minimum WinXP SP2, which is no longer a problem today.
-
Oct 26th, 2016, 07:00 PM
#1178
New Member
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by chosk
If you use VBCCR13 with the side-by-side resource provided, you will never encounter any problem caused by registry in the user computer. Your application will always run no matter what problem there may be with the registry.
The only consideration is minimum WinXP SP2, which is no longer a problem today.
Thank you chosk. However, I have to admit that I have never used a side-by-side resource myself as an Access programmer. The projects are adp or mdb files. The exe file is "msaccess.exe" which opens the project file. From the project file I can add references, but those need to be registered by "regsvr32.exe" first. Could I use a side-by-side resource also? Thanks for your help anyway!
-
Oct 26th, 2016, 07:43 PM
#1179
Hyperactive Member
Re: CommonControls (Replacement of the MS common controls)
Sorry, I missed the part about Access. Probably won't work then.
-
Oct 27th, 2016, 01:56 AM
#1180
Re: CommonControls (Replacement of the MS common controls)
@martin.martin:
Then you should create an installation package to distribute and install the VBCCR13 on client computers.
-
Oct 27th, 2016, 06:35 AM
#1181
New Member
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by Arnoutdv
@martin.martin:
Then you should create an installation package to distribute and install the VBCCR13 on client computers.
Thanks Arnout, however I must admit that I have never created an installation package so far either. I prefer to be honest even if this make me look behind reality ;-) I will go into further investigation whenever I run out of workarounds again.
-
Oct 28th, 2016, 02:02 PM
#1182
Re: CommonControls (Replacement of the MS common controls)
Update released.
Fixed a bug in the Selected property of a Node in the TreeView control.
The issue was that a focused (but not selected) Node could not get the selected state by code.
That bug can be easily replicated by following code:
Code:
TreeView1.Nodes(1).Selected = Not TreeView1.Nodes(1).Selected
The code should toggle the selected state, but it was not working.
However, now it works. (like in the original MS control)
-
Oct 31st, 2016, 12:34 PM
#1183
Lively Member
Re: CommonControls (Replacement of the MS common controls)
what is the latest version (build) of the OCX
-
Nov 2nd, 2016, 04:50 AM
#1184
New Member
Re: CommonControls (Replacement of the MS common controls)
Hi, i have project that already contain *.res file and it can't have more than one *.res file how i can implement this custom control without adding new res file from your project demo/example? because i realize that this control can't working fine without resources.res
-
Nov 2nd, 2016, 06:59 AM
#1185
Junior Member
Re: CommonControls (Replacement of the MS common controls)
Hello Krool, as many others have also said already, thanks for your outstanding work on this control library.
I may have found a slight difference in how VBCCR (still using 12) implements the CommonDialog.FilterIndex property as compared to Microsoft's. Our original code would specify a new value for .FilterIndex, then show the file open dialog, and then again read from .FilterIndex to see what file type the user selected.
Using VBCCR12, the .FilterIndex property does not get updated after the file selection. (It always returns back the same default which was set originally). However, reading MSDN ([1] and [2]) I'm not actually sure what it is supposed to do. It sounds like perhaps it is meant to be used ONLY for setting the default (not for reading the user's selection). But nonetheless the Microsoft version seemed to allow that and even if that was a bug on their part, it is now a difference in behavior.
I'm curious what your opinion of this issue is. Is there an approach for getting the selected filter (other than parsing the selected filename)?
Thanks again!
-
Nov 2nd, 2016, 07:47 AM
#1186
Lively Member
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by Krool
This is the 1.3 ActiveX Control version. (Revision 10)
Not available for the moment, due to forum policy. Please PM me to get it by another way.
I cannot pm you, could you send me the latest ocx please
-
Nov 2nd, 2016, 03:55 PM
#1187
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by DaveInCaz
I may have found a slight difference in how VBCCR (still using 12) implements the CommonDialog.FilterIndex property as compared to Microsoft's. Our original code would specify a new value for .FilterIndex, then show the file open dialog, and then again read from .FilterIndex to see what file type the user selected.
Using VBCCR12, the .FilterIndex property does not get updated after the file selection. (It always returns back the same default which was set originally). However, reading MSDN ( [1] and [2]) I'm not actually sure what it is supposed to do. It sounds like perhaps it is meant to be used ONLY for setting the default (not for reading the user's selection). But nonetheless the Microsoft version seemed to allow that and even if that was a bug on their part, it is now a difference in behavior.
I'm curious what your opinion of this issue is. Is there an approach for getting the selected filter (other than parsing the selected filename)?
Update released.
Thanks
-
Nov 3rd, 2016, 03:44 PM
#1188
New Member
Re: CommonControls (Replacement of the MS common controls)
Last edited by dtencer; Nov 4th, 2016 at 08:25 AM.
Reason: Doesn't add to the conversation
-
Nov 6th, 2016, 05:18 PM
#1189
Re: CommonControls (Replacement of the MS common controls)
Update released.
Fixed a bug in the NoImage property of a Button in the ToolBar control.
It was not possible to set the NoImage property of a Button to True when no ImageList was set.
Beside that, I have noticed another "point":
When an ImageList is set for a ToolBar control and this is changed to Nothing then the spaces for the Images are removed.
However, a ToolBar that has already no ImageList will display these spaces for the Images even when setting again the ImageList property to Nothing.
Only setting a valid ImageList and then setting to Nothing will remove these "spaces". But the spaces will come again if the ToolBar gets re-created.

So, there are then three options, which I hope to get some opinions:
1. keep as described above. (same as MS ToolBar)
2. Never show spaces for the images when there is no ImageList set.
3. Always keep the spaces for the Images in all scenarios.
Last edited by Krool; Nov 7th, 2016 at 04:22 PM.
-
Nov 6th, 2016, 07:45 PM
#1190
Hyperactive Member
Re: CommonControls (Replacement of the MS common controls)
I am not sure where this fall into which of the three options.
When an imagelist is set for the toolbar and there are buttons with images and there are also buttons without images, then for those buttons that do not have images there be no space for the image.
Edit to add:
This to apply only when TextAlignment is set to 1-Right. When TextAlignment is 0-Bottom, then images are expected for all buttons.
Last edited by chosk; Nov 6th, 2016 at 08:28 PM.
-
Nov 7th, 2016, 12:46 AM
#1191
Re: CommonControls (Replacement of the MS common controls)
When ImageList is set all buttons expect images, to exclude a button there is the NoImage property.
But whats for the case when no ImageList is set?
You say for TextAlignment 0-Bottom keep the spaces and for 1-Right remove the spaces, right?
-
Nov 7th, 2016, 01:12 AM
#1192
Hyperactive Member
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by Krool
When ImageList is set all buttons expect images, to exclude a button there is the NoImage property.
But whats for the case when no ImageList is set?
You say for TextAlignment 0-Bottom keep the spaces and for 1-Right remove the spaces, right?
Yes.
Last edited by chosk; Nov 7th, 2016 at 01:19 AM.
-
Nov 7th, 2016, 08:05 AM
#1193
New Member
Re: CommonControls (Replacement of the MS common controls)
Krool,
I have run into an issue that results in VB crashing upon stopping my test app in debug or closing my test app.
I have narrowed it down to this:
If you place as ListView control and a Button control on a form the add this code to the button:
Private Sub CommandButtonW1_Click()
Dim loItem As LvwListItem
For Each loItem In ListView1.ListItems
loItem.Ghosted = False
Next
End Sub
When you close the form or click Stop in debug mode VB6 will crash.
I can workaround this code by doing this:
Private Sub CommandButtonW1_Click()
Dim loItem As LvwListItem
Dim i as integer
For i = 1 to ListView1.ListItems.Count
Set loItem = ListView1.ListItems(i)
loItem.Ghosted = False
Next
End Sub
As I am evaluating using your control, it seems the intent is to have your control replace the CommonControls.
I am just wondering if there was a known list of differences so that I can be sure to make adjustments in my code and avoid any issues?
Any help here would be appreciated.
Thank you
-
Nov 7th, 2016, 12:22 PM
#1194
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by dtencer
Krool,
I have run into an issue that results in VB crashing upon stopping my test app in debug or closing my test app.
I have narrowed it down to this:
If you place as ListView control and a Button control on a form the add this code to the button:
Private Sub CommandButtonW1_Click()
Dim loItem As LvwListItem
For Each loItem In ListView1.ListItems
loItem.Ghosted = False
Next
End Sub
When you close the form or click Stop in debug mode VB6 will crash.
I can workaround this code by doing this:
Private Sub CommandButtonW1_Click()
Dim loItem As LvwListItem
Dim i as integer
For i = 1 to ListView1.ListItems.Count
Set loItem = ListView1.ListItems(i)
loItem.Ghosted = False
Next
End Sub
As I am evaluating using your control, it seems the intent is to have your control replace the CommonControls.
I am just wondering if there was a known list of differences so that I can be sure to make adjustments in my code and avoid any issues?
Any help here would be appreciated.
Thank you
Never noticed such thing. Can you make a demo? (Ensured the issue comes up)
Also do you use the Std-EXE or OCX version?
Beside that, pushing IDE stop button is not recommended, however closing form has to work..
-
Nov 7th, 2016, 12:52 PM
#1195
New Member
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by Krool
Never noticed such thing. Can you make a demo? (Ensured the issue comes up)
Also do you use the Std-EXE or OCX version?
Beside that, pushing IDE stop button is not recommended, however closing form has to work..
I am using the .ocx.
Here is the behavior I am seeing: http://screencast.com/t/jx58rQBWI0C
I've attached a sample program:
Project1.zip
-
Nov 7th, 2016, 03:00 PM
#1196
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by dtencer
I have tested on WinXP and Win7 and it worked fine.. hmm.
Does this happen when sample program is compiled? Does it also happen when using the Std-EXE version?
Did you test on other controls? (e.g. TreeView)
Anyone else having this issue?
Last edited by Krool; Nov 7th, 2016 at 03:04 PM.
-
Nov 8th, 2016, 06:56 AM
#1197
Lively Member
Re: CommonControls (Replacement of the MS common controls)
hi, Thanks Krool (again, I can't stop thanking you)
How often do you update the OCX? I see in the latest revision (10) some thing are not included (like RTL support)
-
Nov 8th, 2016, 07:59 AM
#1198
New Member
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by Krool
I have tested on WinXP and Win7 and it worked fine.. hmm.
Does this happen when sample program is compiled? Does it also happen when using the Std-EXE version?
Did you test on other controls? (e.g. TreeView)
Anyone else having this issue?
It does not happen when compiled. But I have seen an issue like this before and if it does this in debug it will have a negative effect latter on the application. One example is if I compile to a .dll then call from another .exe it will throw an exception.
I have not tried the Sdt-EXE version.
It works fine with the TreeView control, it seems to be isolated to the ListView.
Thanks
-
Nov 8th, 2016, 11:26 AM
#1199
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by dtencer
It does not happen when compiled. But I have seen an issue like this before and if it does this in debug it will have a negative effect latter on the application. One example is if I compile to a .dll then call from another .exe it will throw an exception.
I have not tried the Sdt-EXE version.
It works fine with the TreeView control, it seems to be isolated to the ListView.
Thanks
Ok, difference between TreeView and ListView is following.
TreeView uses native Collection enumeration. ListView uses custom enumeration. (Enumeration.cls)
Because ListView need to be enumerated in visible order and not order of the collection.
I think that some reference is not terminated, thats why the crash.
I await your try with the Std-EXE version. There we can get closer to the cause and find out a solution.
However, as already said, I can not replicate the issue and thus I am dependent on you. :-)
-
Nov 8th, 2016, 11:28 AM
#1200
New Member
Re: CommonControls (Replacement of the MS common controls)
 Originally Posted by Krool
Ok, difference between TreeView and ListView is following.
TreeView uses native Collection enumeration. ListView uses custom enumeration. (Enumeration.cls)
Because ListView need to be enumerated in visible order and not order of the collection.
I think that some reference is not terminated, thats why the crash.
I await your try with the Std-EXE version. There we can get closer to the cause and find out a solution.
However, as already said, I can not replicate the issue and thus I am dependent on you. :-)
Please direct me to instruction on how to test/use the Std-EXE version. I have only just discovered your .ocx.
Thank you
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|