Printable View
I have read about Eduardo's SSTab replacement, which is a good thing.
As I gave up on the original SSTab many years ago, I don't need the replacement.
The TabStrip is good enough for me.
Eduardo's work has the BackColor property.
This would be very useful for the TabStrip as well.
Here:
Attachment 156305
Could this be done for your TabStrip as well?
You have every right to decide what you will focus your time on. It seems odd when a fix is available to improve something you released, yet instead you would rather cast blame. Someone is always to blame, the goal here was to create a solution. Why reject any fix, they are not responsible for the controls you created? If you were confident they would fix it why did you bother to create these *fixed* components in the first place?Quote:
Originally Posted by Krool
MS screw up comctl32.dll? And that affect all controls so created, even MS own? How/who to fix comctl32.dll?
Exactly. Every SysListView32 is affected. So it makes no sense to just make a workaround fix for my wrapper..Quote:
Originally Posted by chosk
There is no native way as COLOR_BTNFACE is hard-coded in comctl32.dll for the SysTabControl32.Quote:
Originally Posted by Karl77
There is a hacky way too workaround that:
http://www.glennslayden.com/code/win...ckground-brush
However, the adjustmants are mainly guessings and very vague. It might work for now but in a newer OS it might be not perfect anymore. So in fact there is no straight forward method to calc. the stuffs needed.
So IMO it's too hacky to implement as a property to trust on.
Ok, I see.Quote:
Originally Posted by Krool
I hoped it would be an easy straightforward thing; it's not.
But the very last method form Paul Sanders on the page seems to be good enough, or?
The background color would be nice.
There are much +- 1, 2 and rounded corners or not. The calculation is done very specific to get perfect result.Quote:
Originally Posted by Karl77
However, for me that's not "straight forward" as in a new themed style the offsets can go wrong. And even DPI scaling is also a factor which is not considered.
So I'm afraid of implementing such a property.
Which is very important..Quote:
Originally Posted by Krool
Full agree, better don't.Quote:
So I'm afraid of implementing such a property.
Hi, Krool !
When typing ALT + 3333 in textbox, '?' is appearing instead of '♣'. Is that a bug?
Thanks.
It's a bug.Quote:
Originally Posted by Dragokas
I need to fiddle with WM_SYSKEYDOWN and WM_SYSCHAR in order to find a solution. (Caching CharCode to avoid VB's ANSI message bump)
Currently this case is not handled..
Thanks for pointing this out. It's not that critical but a weak spot that needs to be handled in order to be "full unicode compatible".
I will come back for this soon.
Update released.
Unicode support when generating ASCII key combos, e.g. ALT + 3333.
Both the Std-EXE version and the VBCCR15.OCX got updated.
In fact it was not necessary (and not applicable) to fiddle with WM_SYSKEYDOWN/WM_SYSCHAR as just WM_KEYUP needed to be cached as well.
When generating ASCII key combos the WM_CHAR is generated actually in WM_KEYUP instead of normally on WM_KEYDOWN. That's it :)
Again thanks to Dragokas for pointing this issue out.
really fast turn around! thanks.Quote:
Originally Posted by Krool
Update released.
Major internal improvement in the VTableHandle.bas module. (thanks to TimoSoft)
The VTableHandle.bas subclassed IOleInPlaceActiveObject, IOleControl, IPerPropertyBrowsing and IEnumVARIANT.
The logic were all "straight forward" except for IOleInPlaceActiveObject as it required some quirky workarounds.
It turned out that subclassing IOleInPlaceActiveObject is not necessary as in IOleInPlaceUIWindow::SetActiveObject you can place any IOleInPlaceActiveObject interface.
So, the new solution is creating an own "lightweight" IOleInPlaceActiveObject VTable which is used on the SetActiveObject. Thus no subclassing required.
The other interfaces IOleControl, IPerPropertyBrowsing and IEnumVARIANT will still need subclassing. But that's no problem as they caused no quirks anyway.
just for curiosity, any reason you gave up on the sstab ? I use it a lot and I was wondering if there were bug I should be aware of ...Quote:
Originally Posted by Karl77
No special bug I remember.Quote:
Originally Posted by VbNetMatrix
I think the main reasons were not displaying perfect with visual styles.
And not being able to disable controls that are not visible.
And the additional dependency.
It can be that my bad experience is from VB3 times, except the visual styles thing.
When SSTab works good for you, fine.
As said, I see no need for me.
Some people seem to think the -75000 pixel unit .Left is a bug for hidden tab as in fact is a feature. we can live well with it when testing for it.Quote:
Originally Posted by Karl77
didn't experienced thatQuote:
Originally Posted by Karl77
You need to put a picture box in Each tab, use it as a container and disable that container on requirement. work wellQuote:
Originally Posted by Karl77
Refular Stab also got aditional dependency isn't ??Quote:
Originally Posted by Karl77
Since activating Visual managment from Vb6 cause more bug then the definitive improve gain experience, I have created my own visual component to have a good look and feel inside my program, so I didn't experienced that.Quote:
Originally Posted by Karl77
what I love most is the fact you can place your stuff in the IDE on each different TAB and manage each Tab independently and manage from there, it's easier to build your program interface.Quote:
Originally Posted by Karl77
VbNetMatrix
Don't let us hijack Krool's thread...
Same procedure as with TabCtl.Quote:
Originally Posted by VbNetMatrix
While I would expect from a SSTab that it manages this on it's own.
Yes, to Comctl32.ocxQuote:
Refular Stab also got aditional dependency isn't ??
Which is very well substituted by the VBCCR controls.
In fact there is only one single dependency for all the controls needed for a 'normal' UI.
Or no dependency if you work with the EXE version.
Hmm? Not nearly true.Quote:
Since activating Visual managment from Vb6 cause more bug then the definitive improve gain experience,
For me, this is a very minor benefit, if at all.Quote:
what I love most is the fact you can place your stuff in the IDE on each different TAB and manage each Tab independently and manage from there, it's easier to build your program interface.
Agree... let's focus on Krool project...Quote:
Originally Posted by Karl77
not sure I follow... Krool is not totally replacment since it depend on original control. It's improvment of original control, meaning it require the SAME dependency or do I miss something ?Quote:
Originally Posted by Karl77
what about the documentation about the installation and use of the EXE version ? is it completed yet ?
Not true.Quote:
Originally Posted by VbNetMatrix
The VBCCR control base is comctl32.dll (part of the OS).
Yes, you do...Quote:
It's improvment of original control, meaning it require the SAME dependency or do I miss something ?
The best thing is, you start reading this thread from the very first post on.
Then you should know 'everything'.
No need for an installation, just copy the folders and files.Quote:
what about the documentation about the installation and use of the EXE version ? is it completed yet ?
You can see all the needed coding in the demo.
Again, you should read this in the first few posts.
http://www.vbforums.com/showthread.p...=1#post4277565
Update released.
Included the VirtualMode/VirtualItemCount property and GetVirtualItem/FindVirtualItem event in the ListView control.
When there are over 100,000 items it is worth to consider virtual mode as the VB6 class destruction (ListItems collection) will get slow at some point.
This issue is not existent on virtual mode as all the data can be cached in a recordset or private array.
The new VirtualControlsForm in the demo project demonstrates an example usage of the virtual list view.
All normal list view events are supported, e.g. ItemClick. However, passed ListItem objects in these events are limited in their functionality when VirtualMode is on.
Several functions/properties/methods are disabled (error raise) when VirtualMode is on. (e.g. Tile view, Groups, Sorting, ListItems collection etc.)
Also included VirtualDisabledInfos property that allows to disable not needed virtual properties and to increase performance. (less GetVirtualItem event calls)
Attachment 156865
At run-time that property can be changed.
Code:ListView1.VirtualDisabledInfos = 0 ' None disabled info
ListView1.VirtualDisabledInfos = LvwVirtualPropertyForeColor + LvwVirtualPropertyBold ' Disable CustomDraw callbacks
Hi Krool,
First I'd like to say a big thank you for putting lots of effort in this project!
I'm facing a problem when trying to implement the TextBoxW control in a project of mine.
The problem is very easily reproducible.
1. Create an ActiveX Control project 'MyButton'.
Drag a CommandButton on the control.
Assign the following code:
Attachment 156885
2. Make a new VB project, Project1.vbp, which has Form1.
Drag a TextBoxW control and the newly created MyButton control on it.
Attachment 156883
3. Now unload Form1 when MyButton is clicked:
Attachment 156887
:thumb: When the button is clicked via left mouse button, the form unloads correctly.
:down: When the button is clicked via the keyboard enter, the project crashes.
Additional information:
If the TextBoxW control is replaced by LabelW, FrameW or ImageList. The project doesn't crash.
If the TextBoxW control is replaced by any other control, the same error occurs.
Update released.
Potential crash in the GetVirtualItem event fixed in the ListView control.
Hi Krool,
I am starting another project same as one I did in end-2016 but this time, I hit a problem with the TabStrip. I am using Std-EXE. Then I tested the older control builds and the last control build that do not have the problem is 5-May-2017. Tabstrip after this date up to the latest has the problem.
The project is a MDI project that is:
1) Using TabStrip as MDI Tabs
2) Child form's tag is set to "Chart"
3) Child form's .WindowsState is always = vbMaximized
4) Child form's .Visible = True or False, depending on tab selected
The problem is that child forms momentarily show as vbNormal (in a flicker) whenever the TabStrip is clicked. When tab is already selected and shown and tab clicked again, the child form show as vbNormal. There is no code to show it vbNormal.
TabStrip_TabClick codes:
I attached two video to show, using 5-May-2017 and 2-Mar-2018. The versions is shown in the MDI Parent caption.Code:Private Sub TabStrip_TabClick(ByVal TabItem As TbsTab)
Dim i As Integer
'Do two loops to prevent potential problems
'First, hide all child forms
For i = Forms.Count - 1 To 0 Step -1
If Forms(i).Tag = "Chart" Then
Forms(i).Visible = False
End If
Next
'Then, show only selected child form
For i = Forms.Count - 1 To 0 Step -1
If Forms(i).Tag = "Chart" Then
If Forms(i).Symbol = TabItem Then
Forms(i).Visible = True
End If
End If
Next
End Sub
Important update released.
@ MBOS,
I could not replicate your scenario. However, I was able to get such a crash in another context/scenario (for me like a random scenario).
My scenario though was only replicable in the IDE and not on the executable.
I was able to find the cause for it and the explanation.
Due to the VTableHandle.bas update on 25-Feb-2018 the IOleInPlaceActiveObject switched from Subclassed to own lightweight VTable object.
The issue is that the lightweight VTable object relies on AddressOf functions and that these addresses could go "invalid" (addresses in .bas module changed) on unload.
The straight forward solution was now to restore the original IOleInPlaceActiveObject object in the DeActivateIPAO method. So it is safe in either case to unload.
I did that... still don't understand... something is incredibly easy for me like programming.... and other are incredibly complex, like managing a smart phone. And I read this forum since the first post and unless it changed since I read it, I still don't understand.Quote:
Originally Posted by Karl77
Hi Krool,
I am happy to continue using the 5-May-2017 version of TabStrip for my current project because this serve my purpose. I just need to include the improvement/fixes to DPI-Aware that were in the 25 and 26 Jul 2017 releases. I believe these two releases fixed the DPI-Aware problem reported in post #1500:
http://www.vbforums.com/showthread.p...=1#post5189339
If you could let me know where do I make the changes, I will be more than happy to do it myself.Quote:
26-Jul-2017
- Bugfixes related to 25-Jul-2017 update in the TabStrip, ToolBar and CoolBar control.
25-Jul-2017
- Pixels in property bags are now treated as DIPs. (Device-independent pixels)
There is no compatibility break in the property bags when there were saved at 100% (96) DPI.
Included new functions PixelsPerDIP_X/PixelsPerDIP_Y in Common.bas.
This "DPI Aware" enhancement affects the TabStrip, ToolBar, Pager and CoolBar control.
VbNetMatrix
2 possibilities:
1) Take the complete EXE demo. Delete all that you don't need. Add your code into this project.
2) Use the OCX version. Usage is as with other OCX's.
Can I offer my help with some screenshots? The steps is really easy and simple to add only the control/s needed.
I normally use my own module, eg, MainModule.bas, and the Main function within and do not drag-and-drop the Startup.bas. These screenshots here is only for example.
My issue also seems to be solved! :)Quote:
Originally Posted by Krool
Chosk,
Yes no problem I can tell you the lines to change for DPI Aware.
However, I would like to first try to find the cause of the flicker problem in the latest TabStrip control..
@ MBOS, great. I have the feeling now I never need to touch VTableHandle.bas again. It's done now. :D
Hi Krool,Quote:
Originally Posted by Krool
Now, I do not know whether the cause is in the TabStrip. I just tested using a ListBoxW, instead of TabStrip, and same flicker and child form windowstate become Normal also happen in the latest release but not with the 5-May-2017 release.
WM_MOUSEACTIVATE was changed after 5-May-2017 release on all controls. Looks now like its coming from that change..Quote:
Originally Posted by chosk
the OLEGuids.tlb supplied. is this a replacement for the one provided by windows, or do I still need to keep the original
It's a custom tlb. It's only needed in the IDE on the dev PC. At the run-time (end user) it's not needed.Quote:
Originally Posted by Semke
PAGER FEATURE WISH/QUESTION
I use the pager control a lot.
The AutoScroll feature is quite handy.
For this, the mouse must hover over the pager button.
Very ok so far.
It would be even more comfy if I could use the mouse wheel in addition to the buttons.
While being somewhere in the pager area.
And not over a control which makes use of the wheel message.
Is this possible at all?
WOW Krool. You've made Wikipedia. :)
thank you, I know that its a custom tlb. does it also include all the other types which are in the original OLEGuids.tlbQuote:
Originally Posted by Krool
Ok, I added WM_MOUSEWHEEL in WindowProcControl.Quote:
Originally Posted by Karl77
The message comes in, and controls in the pager do work as usual regarding the mouse wheel.
Looks promising.
I don't know how to make the pager scroll.
Do I really need to get+set the position, or is there a function/message for it?
EDIT:
Too easy.
I can just make use of the Value property.
Problem solved.
EDIT 2:
Once again a good example for the benefit to have access to the sources.
GetTitleBarHeight
In Common.bas, there is the handy GetTitleBarHeight function.
I think there is something wrong.
It adds the frame 2x, while it should 1x only.
At least to my measurements.Code:Select Case Form.BorderStyle
Case vbSizable, vbSizableToolWindow
CY = CY + (GetSystemMetrics(SM_CYSIZEFRAME) * 2)
Case vbFixedSingle, vbFixedDialog, vbFixedToolWindow
CY = CY + (GetSystemMetrics(SM_CYFIXEDFRAME) * 2)
End Select
For my usage the 2x is correct. The naming is maybe a little bit misleading..Quote:
Originally Posted by Karl77
In fact Form.Height contains the ScaleHeight and the "outer" height. I use the GetTitleBarHeight to exclude the "outer" height.
So I can apply something like following:
The 120 twips is just a buffer then between a ListView and a StatusBar.Code:Me.Height = GetTitleBarHeight(Me) + (ListView.Top + ListView.Height) + StatusBar.Height + 120
Edit: A better name for it could be 'GetNonScaleHeight'. ^^
Edit 2: The ListView in my code example is of course in a variable height setup at Form_Load, otherwise such calculation would be meaningless.
(GetTitleBarHeight)
I didn't inspect your usage of the function - of course it is correct for you.Quote:
For my usage the 2x is correct.
GetTitleBarHeight came into my view when I searched for a constant in my code.
And hey, I found a ready function, the name expresses exactly what I wanted.
My fault that I didn't look more in detail.