Re: CommonControls (Replacement of the MS common controls)
Originally Posted by chosk
No one will be able to do this if Krool's controls are not to MS behavior.
Full agree.
100% compatibility is the very main thing.
This makes it 'simple' to refresh an old app with the Krool's new controls.
If this wouldn't be the case, and we would have to think about every nitty-gritty detail, it would be more cumbersome.
Even with this 100% compatibility, there is enough to consider and re-code.
Which doesn't mean there shall be no new features.
There are a LOT of new and better features in the Krool controls.
If they were not there, the replacement wouldn't make any sense.
So all is right.
---
I myself fell into the 'break compatibility' trap, as I thought in #1691.
That was not a good idea.
Re: CommonControls (Replacement of the MS common controls)
.
.
I was just typing a reply till I saw your posts . I have nothing to say here . Although I am holding much .
About krool ,
he can read and determine if I said he was wrong or not . I am not (technically) in a position to judge krool or Microsoft . I was opening a discussion accepting the fact that I might be totally wrong due to a missing info .
About
feature request
I do not find it shameless to me to ask for any type of help . So , if I needed it , I would have asked for it because I am here to learn and I have already asked in the way which I find too clean and you suspect "my intentions" , go ahead . Also , I appreciate what krool is doing and for free helping all folks here including you . No need to be the bad guy here . Also , everyone can see that I did not do anything wrong to you or to anybody .
About being
polite
I think it is me who can teach you such thing .
How about this? Then listview1.listitems(i).ForeColor = -1 will not be executed when not necessary.
.
this line was intentionally written like this because it was in a separate clear_format function where this method for comparison could not be done due to the changing operands , operators , parameters , colors and columns being tested . So , I had to clear all and set all to -1 before assigning new colors and I had copied it in here . So , you Just wanted to show off and fix what you considered an error . Even if it is , I do not mind . I am totally self-confident and do not need to search and seek for a kiddy comment to prove something .
Sorry if I am rude again although I know you like to say you don't have problem with coding
Seems we both have problems but yours is the one I find shameless to have .
Such type of speech is time-wasting . I will not reply to any of your posts or whatever you say here for many reasons .
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Arnoutdv
The source code is also available, so if you want to create a personal version I think you are free to do so!
yes Arnoutdv , but I am not even willing to do so . As I said it is not a problem for me (the performance issue) . I have no problem with looping affecting performance in my apps level as I said . So , I thought this might be useful to anyone . It might be right or wrong .
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Hosam AL Dein
yes Arnoutdv , but I am not even willing to do so . As I said it is not a problem for me (the performance issue) . I have no problem with looping affecting performance in my apps level as I said . So , I thought this might be useful to anyone . It might be right or wrong .
You've made a great and logical argument, and no one is saying you are wrong on those merits.
However considering it is subjective behavior (arguable either way), Microsoft chose differently.
Considering this project is a replacement of Microsoft's controls - compatibility completely over rides any subjective differences in logic.
And now comes the beauty of open source - If you want a behavior that's different from how Microsoft has done it for the last 20+ years, anyone can fork / change it.
Re: CommonControls (Replacement of the MS common controls)
I don't want to deepen the discussion about the forecolor in the ListView too much further, but:
Like others said it is essential that an replacement set does replace as flawless as possible.
So in fact it doesn't matter who is right or wrong with the ListView ForeColor'ing, the replacement must fulfill the MS behavior.
As an example even that can be tricky. For example the ListView 5.0 does have in one point an other behavior than the ListView 6.0
The ListView 5.0 will not autoselect the first listitem added to the list, whereas the ListView 6.0 does.
So which behavior should I take? Both seems to be "correct"?
I then decided to bring up a property called "AutoSelectFirstItem". It's default value is True.
When True it behaves like MS ListView 6.0, when False it does behave like MS ListView 5.0.
So everyone can decide which behavior to follow. I have chosen the MS ListView 6.0 behavior as default because my assumption was that the most will likely replace the MS ListView 6.0 and not an 5.0 one.
Re: CommonControls (Replacement of the MS common controls)
I think that we should be able to make everybody happy with this. I am not convinced that Hosam necessarily wants his desired feature to be the default and break compatibility with the MS version. I am guessing that if there were a new method added that is separate from and in addition to the MS methods that could be called then Hosam would be happy because he could do what he wants to do and everyone else should be happy because they can keep the MS compatibility and also have the option to use the new "Hosam method." Krool, this doesn't sound too hard to add another method (my guess is that would be better than creating a new fork), is this something you would like to add?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by MountainMan
I think that we should be able to make everybody happy with this. I am not convinced that Hosam necessarily wants his desired feature to be the default and break compatibility with the MS version. I am guessing that if there were a new method added that is separate from and in addition to the MS methods that could be called then Hosam would be happy because he could do what he wants to do and everyone else should be happy because they can keep the MS compatibility and also have the option to use the new "Hosam method." Krool, this doesn't sound too hard to add another method (my guess is that would be better than creating a new fork), is this something you would like to add?
MountainMan
After thinking this through, I can see why Microsoft decided to go the way they did. To me it seems non-intuitive that by setting a default ForeColor - you are also resetting all previously set individual colors. It's kind of like completely erasing the bitmap on a form, by setting the BackColor. (which is the default behavior)
So what you/ Hosam are proposing is something like a ForeColorReset(), which removes all individual colors.
Last edited by DEXWERX; Sep 12th, 2017 at 01:19 PM.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by DEXWERX
After thinking this through, I can see why Microsoft decided to go the way they did. To me it seems non-intuitive that by setting a default ForeColor - you are also resetting all previously set individual colors. It's kind of like completely erasing the bitmap on a form, by setting the BackColor. (which is the default behavior)
So what you/ Hosam are proposing is something like a ForeColorReset(), which removes all individual colors.
As far as I also understood is that he needs a method to erase all customizing colors of the listitems (and subitems).
I have in mind a "ResetForeColors" method in .ListItems.
Means (syntax):
Code:
ListView1.ListItems.ResetForeColors
That method would actually just set the ForeColor of all ListItems and ListSubItems back to -1. (equal ListView.ForeColor)
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by DEXWERX
You've made a great and logical argument, and no one is saying you are wrong on those merits.
However considering it is subjective behavior (arguable either way), Microsoft chose differently.
Considering this project is a replacement of Microsoft's controls - compatibility completely over rides any subjective differences in logic.
And now comes the beauty of open source - If you want a behavior that's different from how Microsoft has done it for the last 20+ years, anyone can fork / change it.
This was the main reason for opening this discussion DEXWERX . We put all merits and demerits on a scale and then come up with a solution which takes main and essential functions into consideration . Is this right ? what is the reason for this behavior ? can we change it ? if no , so what can we do to solve it ? how will this solution affect the control ? and so on . This was the way of discussion I was expecting and asking for and it seems we have reached to this point and I am happy with that .
Originally Posted by Krool
Like others said it is essential that an replacement set does replace as flawless as possible.
Totally agree with this point , krool .
Originally Posted by MountainMan
I think that we should be able to make everybody happy with this. I am not convinced that Hosam necessarily wants his desired feature to be the default and break compatibility with the MS version.
You got the main point and said all what I want to express ,MountainMan
Originally Posted by DEXWERX
After thinking this through, I can see why Microsoft decided to go the way they did. To me it seems non-intuitive that by setting a default ForeColor - you are also resetting all previously set individual colors. It's kind of like completely erasing the bitmap on a form, by setting the BackColor. (which is the default behavior).
Yes DEXWERX , regardless of the solution and its effects , I have been asking myself why they had choosen this behavior and this maybe some logic they adopted .
Originally Posted by Krool
As far as I also understood is that he needs a method to erase all customizing colors of the listitems (and subitems).
I have in mind a "ResetForeColors" method in .ListItems.
Means (syntax):
Code:
ListView1.ListItems.ResetForeColors
That method would actually just set the ForeColor of all ListItems and ListSubItems back to -1. (equal ListView.ForeColor)
The same could be done for the TreeView:
Code:
TreeView1.Nodes.ResetForeColors
Thanks krool for providing a suitable solution but does this mean you are going to add it or you suggest this solution to be added by anyone who wants this feature ?
Anyway , thanks all for getting us to a useful end point and lets continue to work to a next step forward
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Hosam AL Dein
but does this mean you are going to add it or you suggest this solution to be added by anyone who wants this feature ?
The method ResetForeColors is now included into the ListView control. (also TreeView control)
I have put it now directly to the ListView and not to .ListItems.
Means (syntax)
Code:
ListView1.ResetForeColors
The method should be quite fast, even on large lists.
Re: CommonControls (Replacement of the MS common controls)
I use a Krool toolbar which is changed by code quite often while it is visible.
The toolbar flickers in it's whole size when I set another image for a single button.
It also flickers when I set the same image that was already set.
Toolbar1.Buttons(i).Image = "otherimage"
The image comes from a Krool imagelist.
I already tried to set the toolbar to DoubleBuffer = true.
Still flickers.
The MS original via comctl32.ocx does not flicker, not a little bit.
Is there a special trick to get rid of the flicker with the Krool toolbar?
Perhaps I miss something...
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by MountainMan
When will you release v1.5 ? What did you decide to about incorporating FlexGrid into this project or leaving it separate?
v1.5 will be released still this year imo. The FlexGrid will remain separated.
Originally Posted by Dragokas
Can you please append VisualStyles.bas module with *_W2K functions of subclassing like you done in 'ComCtlBase' ?
There is no need to include *_W2K functons in VisualStyles.bas module as those will be used only when "GetComCtlVersion >= 6".
And this is not the case in W2K. That's why there will be no subclassing applied.
Originally Posted by Dragokas
Also, I noticed that program crashes if OS has no installed printers and you click => RichTextBox Demo => Page Setup => Cancel.
The dialog returns CdlPrinterNotFound error. This can be easily fixed in the RichTextBox Demo by adding an Error Handler. Will do that. Thx
Originally Posted by Karl77
The toolbar flickers in it's whole size when I set another image for a single button.
It also flickers when I set the same image that was already set.
I see. I have a solution in mind and will be fixed very soon.
Re: CommonControls (Replacement of the MS common controls)
There is no need to include *_W2K functons in VisualStyles.bas module as those will be used only when "GetComCtlVersion >= 6".
And this is not the case in W2K. That's why there will be no subclassing applied.
Your program crashes on Win2k currently (checked on Win 2k Server SP4 Rollup 2). I added aliases #410/412/413, and it works fine now. I didn't dig deeply to know how and where your subclassing is initiated.
But I know that aliases solved problem for me.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Dragokas
Your program crashes on Win2k currently (checked on Win 2k Server SP4 Rollup 2). I added aliases #410/412/413, and it works fine now. I didn't dig deeply to know how and where your subclassing is initiated.
But I know that aliases solved problem for me.
In my VM for W2K it does not crash.
Can you remove the aliases again and and comment following out: (green marked)
Code:
Public Sub SetupVisualStyles(ByVal Form As VB.Form)
If GetComCtlVersion() >= 6 Then SendMessage Form.hWnd, WM_CHANGEUISTATE, MakeDWord(UIS_CLEAR, UISF_HIDEFOCUS Or UISF_HIDEACCEL), ByVal 0&
If EnabledVisualStyles() = False Then Exit Sub
Dim CurrControl As Control
For Each CurrControl In Form.Controls
Select Case TypeName(CurrControl)
Case "Frame"
SetWindowSubclass CurrControl.hWnd, AddressOf RedirectFrame, ObjPtr(CurrControl), 0
Case "CommandButton", "CommandButtonW", "CheckBox", "CheckBoxW", "OptionButton", "OptionButtonW"
If CurrControl.Style = vbButtonGraphical Then
If CurrControl.Enabled = True Then SetProp CurrControl.hWnd, StrPtr("Enabled"), 1
SetWindowSubclass CurrControl.hWnd, AddressOf RedirectButton, ObjPtr(CurrControl), ObjPtr(CurrControl)
End If
End Select
Next CurrControl
End Sub
Does it still crash? And what does GetComCtlVersion() returns in your W2K?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Dragokas
Sorry, Krool, I don't feel well and my answers took a long time.
I think problem is more complicated. Here what I have:
I have 2 states now of VMWare:
1) Fresh install Rollup 2:
Compiled exe crashes.
2) Fresh install Rollup 2 + VB6 IDE installed:
Compiled exe is NOT crashes.
In IDE - crashes.
There was also error on line:
Code:
Err.Raise Number:=91, Description:="To use this functionality, you must provide a manifest specifying comctl32.dll version 6.0 or higher."
but I commented it. And I sure you specificially created it.
Anyway, do you think problem with compiled EXE arises due to some missing dll in OS?
I'll try to get crash dump.
---
BTW, about subclassing, please forget what I wrote, I confused the source of the problem.
Your issue is solved when you do: (see Notes in first Post) In order to trap error raises via "On Error Goto ..." or "On Error Resume Next" it is necessary to have "Break on Unhandled Errors" selected instead of "Break in Class Module" on Tools -> Options... -> General -> Error Trapping.
Re: CommonControls (Replacement of the MS common controls)
I decided to compare snapshots with ProcMon.
I found that after adding such reg fix:
Code:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}]
@="VBPropertyBag"
[HKEY_CLASSES_ROOT\CLSID\{D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}\InProcServer32]
@="C:\\WINNT\\system32\\MSVBVM60.DLL"
"ThreadingModel"="Apartment"
ComCtlsDemo.exe is no longer crashes on fresh Win 2k without VB6 IDE installed.
Re: CommonControls (Replacement of the MS common controls)
Update released.
Improvement in the CommonDialog.cls. However, the improvement is only meaningful for the ActiveX Control version.
The owner window of an dialog box was determined as following:
Code:
If Not Screen.ActiveForm Is Nothing Then
.hWndOwner = Screen.ActiveForm.hWnd
Else
.hWndOwner = GetActiveWindow()
End If
But 'Screen' will certainly not be meaningful from within the ActiveX Control. It will only be properly in the Std-EXE Version.
Now in order to work in both worlds the 'Screen' object needs to be eliminated. (like it was done with the 'Printer' object before)
Now the owner window for the dialog box is retrieved via API with an helper function in CommonDialog.cls:
Code:
.hWndOwner = GetOwnerWindow()
Private Function GetOwnerWindow() As Long
Dim hWnd As Long, hWndMDIClient As Long
hWnd = GetActiveWindow()
If hWnd <> 0 Then hWndMDIClient = FindWindowEx(hWnd, 0, StrPtr("MDIClient"), 0)
If hWndMDIClient <> 0 Then
Const WM_MDIGETACTIVE As Long = &H229
GetOwnerWindow = SendMessage(hWndMDIClient, WM_MDIGETACTIVE, 0, ByVal 0&)
Else
GetOwnerWindow = hWnd
End If
End Function
Originally Posted by Karl77
The toolbar flickers in it's whole size when I set another image for a single button.
It also flickers when I set the same image that was already set.
This was fixed by changing 'ClipControls' to True in the UserControl of the ToolBar.
Originally Posted by Dragokas
Is it can be fixed somehow?
No, I have no influence about missing registration key of "VBPropertyBag" on W2K.
Re: CommonControls (Replacement of the MS common controls)
Label CCVerticalAlignmentCenter vs. TextBoxW
I discovered this option recently and thought 'nice, now it's easy to align a label to a textbox'.
But now I see it's not perfect.
The label's text is not vertically centered correct.
It is 1 pixel too low.
Re: CommonControls (Replacement of the MS common controls)
Update released.
Major memory usage reduction in the ListView control. The text for the list and list sub items are now retrieved via callback. (LPSTR_TEXTCALLBACK)
Before this update the text for a list item (or list sub item) was stored in a class and also in the API ListView.
Now the text strings are only stored once in the class.
The TreeView, for instance, works different. The text for the nodes are not stored in the class and only in the API TreeView.
So there is actually no need for a callback, so it remains now like it is.
Reason why in the ListView the texts are stored in a class is easy to explain by few examples: (why the texts must be persisted in the class)
- The ListItems and ListSubItems can be created before creating the ColumnHeaders.
- The ListSubItems can be created in any View. So it is possible to change the View later on.
And, by the way, the MS ListView works internally also via LPSTR_TEXTCALLBACK.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Karl77
Label CCVerticalAlignmentCenter vs. TextBoxW
I discovered this option recently and thought 'nice, now it's easy to align a label to a textbox'.
But now I see it's not perfect.
The label's text is not vertically centered correct.
It is 1 pixel too low.
(the red cross is 1 pixel)
The TextBoxW vertical alignment is Top, that's why at some point there will be an offset.
But when I set the TextBoxW and LabelW Height to 255 the offset is 0.
When setting the Height to 315 the offset is 1 and will increase the more the Height is.
Again such thing is expected as the vertical alignment of the TextBoxW is Top.
Re: CommonControls (Replacement of the MS common controls)
Also the border on the TextBoxW pushes the text down and right slightly (probably 1 pixel). So if possible, make the LabelW's height smaller (instead of same as TextBoxW's) to account for the TextBoxW border for better alignment.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by chosk
Also the border on the TextBoxW pushes the text down and right slightly (probably 1 pixel). So if possible, make the LabelW's height smaller (instead of same as TextBoxW's) to account for the TextBoxW border for better alignment.
I don't like the idea so very much.
The good thing with the label's vertical centering is to not have to think about this...
EDIT:
Last paragraph removed, that was nonsense.
Last edited by Karl77; Sep 19th, 2017 at 03:38 PM.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Karl77
Textbox problem
In my program I have a routine that selects all text in a textbox when it gets the focus (optional).
This doesn't work with TextBoxW so very well.
Code:
Private Sub TextBoxW1_GotFocus()
With TextBoxW1
.SelStart = 0
.SelLength = 999
End With
End Sub
The effect is, that the text gets selected from the start to the clicked point.
The intrinsic textbox doesn't show this behavior.
The text gets completely selected as intended.
I did a test with an intrinsic VB TextBox and the TextBoxW:
Code:
Private Sub Text1_GotFocus()
With Text1
.SelStart = 0
.SelLength = 999
End With
End Sub
Private Sub TextBoxW2_GotFocus()
With TextBoxW2
.SelStart = 0
.SelLength = 999
End With
End Sub
Both do select the whole text at GotFocus but the mouse click changes the length of selection to actual clicked point.
So in my point behavior is exactly the same.
EDIT:
Proper implementation of AutoSelect by OnFocus would be as following:
Code:
Private Sub TextBoxW2_GotFocus()
If GetMouseStateFromMsg() = 0 Then
With TextBoxW2
.SelStart = 0
.SelLength = Len(.Text)
.Tag = "Focused"
End With
End If
End Sub
Private Sub TextBoxW2_LostFocus()
TextBoxW2.Tag = vbNullString
End Sub
Private Sub TextBoxW2_MouseUp(Button As Integer, Shift As Integer, X As Single, Y As Single)
With TextBoxW2
If .SelLength = 0 And .Tag = vbNullString Then
.Tag = "Focused"
.SelStart = 0
.SelLength = Len(.Text)
End If
End With
End Sub
EDIT2:
I could include an "AutoSelectOnFocus" property which would take care of this internally.
Re: CommonControls (Replacement of the MS common controls)
The intrinsic works different from my view and experience.
It is forgiving regarding the mouseclick.
Originally Posted by Krool
I could include an "AutoSelectOnFocus" property which would take care of this internally.
Highly appreciated.
I need the tag property for other things.
Thank you very much.
EDIT:
I'm not sure if "AutoSelectOnFocus" is enough.
This would cover only the case when all shall be selected.
There are other behaviors which require different handling.
All with GotFocus by mouse click into the textbox.
A: Move the cursor to the end
B: Select all and move cursor to the end
C: Select all and move cursor to the start
D: Do nothing, just leave the cursor where it was set by click
As said, no problem with the intrinsic textbox.
If all this should happen in the textbox control, I would need "OnFocusSelectMode".
Wouldn't it be easier to swallow the mouseclick 1x?
EDIT2:
It seems to be a completely different problem.
See from #1758 on.
Last edited by Karl77; Sep 20th, 2017 at 02:21 AM.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Can you please provide a Demo showing the different behaviors?
In the standard textbox, if the click is short (normal click), the selection that was made in the GotFocus event is preserved, but if the mouse button is hold pressed down a bit more time (longer click), in that case the end of selection changes to the clicking point.
Yes, interesting. But it is not my TextBoxW which is causing this.
You can put any blank UserControl with 'CanGetFocus' to True on the Form.
The issue also only happens when you click on the VB.TextBox from an VB.UserControl. When you click from the VB.CommandButton to the VB.TextBox you have your expected behavior.
EDIT: Again it is better behavior to select all in GotFocus by tab key and in MouseUp when clicking. In MouseUp also only all text will be selected if SelLength is 0. Thus the user is still free to select partially text without overriding. (See my example above)
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Yes, interesting. But it is not my TextBoxW which is causing this.
You can put any blank UserControl with 'CanGetFocus' to True on the Form.
The issue also only happens when you click on the VB.TextBox from an VB.UserControl. When you click from the VB.CommandButton to the VB.TextBox you have your expected behavior.