In the first post in this thread is the Std-EXE version. On that Demo you can actually test. You may need only to copy the OLEGuids.tlb in your SysWoW64 (64bit OS) or System32 (32bit OS) path first.Quote:
Originally Posted by dtencer
Printable View
In the first post in this thread is the Std-EXE version. On that Demo you can actually test. You may need only to copy the OLEGuids.tlb in your SysWoW64 (64bit OS) or System32 (32bit OS) path first.Quote:
Originally Posted by dtencer
I update the OCX only for internal improvements or bugfixes. Additional features are not implemented to ensure compatibility.Quote:
Originally Posted by Semke
The new features are collected and will be implemented all together in the next OCX release. (would be then VBCCR14.OCX)
I have thought about this and came to the conclusion that by default the MS behavior should be respected.Quote:
Originally Posted by chosk
Therefore when no ImageList is set the default image dimension will be set. Due to a bug in my ToolBar (and also in MS ToolBar) the image dimensions were set to 0x0 when removing an ImageList after a valid ImageList was set. I have fixed this bug now by setting the default dimensions "back" via TB_SETBITMAPSIZE.
But, as a second step, there could be also new properties to have actually control of what behavior you want to have.
So the new properties could be called "DefaultImageWidth" and "DefaultImageHeight" and would contain the image dimensions if no ImageList is set. (so called Default)
Of course, these properties would be set on init to the MS image dimensions to have the MS behavior.
But by changing these properties, e.g. to 0x0, you can actually then change the behavior.
What do you think?
Good.Quote:
Originally Posted by Krool
Update released.
Bugfix in the ToolBar control, quite important in my opinion.
The bug appeared when all buttons have no caption and at least one button has the AutoSize property set to true.
That resulted in a messed up ButtonWidth/ButtonHeight property.
Again update released. This time an internal improvement.
WM_SETREDRAW was replaced with the LockWindowUpdate API in all internal ReCreate methods.
Problem was when the size of a control changed while the redraw state was locked, a "ghost" painting occured.
This will not happen with the LockWindowUpdate API, as it will invalidate the old bounding rectangle, forcing an eventual redraw.
Also LockWindowUpdate will not clear the WS_VISIBLE style bit, thus it is not necessary to check the visibility anymore.
The only downside is that LockWindowUpdate can only lock one window at a time.
So if another window is already locked then the ReCreate method will not clear the locking to break nothing. If that's the case there is no other option to have no locked redraw state, which results then in a flicker.
So the pros outweigh that single disadvantage of an eventual flicker when another window is already locked.
So instead of
now:Code:Private Sub ReCreate[...]
Dim Visible As Boolean
Visible = Extender.Visible
With Me
If Visible = True Then SendMessage UserControl.hWnd, WM_SETREDRAW, 0, ByVal 0&
[...]
If Visible = True Then SendMessage UserControl.hWnd, WM_SETREDRAW, 1, ByVal 0&
.Refresh
End With
End Sub
Code:Private Sub ReCreate[...]
Dim Locked As Boolean
With Me
Locked = CBool(LockWindowUpdate(UserControl.hWnd) <> 0)
[...]
If Locked = True Then LockWindowUpdate 0
.Refresh
End With
End Sub
Update relased.
Finally the Transparent property is included in the ToolBar control.
DEXWERX has requested this twice. :)
Quote:
Originally Posted by DEXWERX
But, TBSTYLE_TRANSPARENT was not used for the Transparent property. It was implemented only to have the BackColor property shown/visible at design-time.Quote:
Originally Posted by DEXWERX
Instead, like in the other controls where a Transparent property is available, it makes a replica of the underlying background. (simulated transparency)
However, the property is ignored when the control paints via double-buffering. (same as BackColor; only working when DoublerBuffer = False)
I love these controls, but I'm struggling with the DT Picker. Everything is as expected, apart from GetDayBold. Here's the code I am currently using but the behivior seems to happen in all cases even if i replace my code with the demo code
(Date2US formats as mm/dd/yyyy string)Code:Private Sub dtp_CalendarGetDayBold(ByVal StartDate As Date, ByVal Count As Long, State() As Boolean)
Dim rs As New ADODB.Recordset
If Not QCOnly Then
Set rs = LoadDatabase.Execute("SELECT DateDue, Count(*) AS [OrderCount] FROM Orders WHERE DateDue Between #" & Date2US(StartDate) & "# And #" & Date2US(StartDate + Count - 1) & "# AND HospitalCode = '" & HospitalCode & "' AND Hidden = False GROUP BY DateDue ORDER BY DateDue")
Else
Set rs = LoadDatabase.Execute("SELECT DateDue, Count(*) AS [OrderCount] FROM Orders WHERE DateDue Between #" & Date2US(StartDate) & "# And #" & Date2US(StartDate + Count - 1) & "# AND Investigation = 'Point Source' GROUP BY DateDue ORDER BY DateDue")
End If
Do While Not rs.EOF
State(DateDiff("d", StartDate, rs.Fields("DateDue")) + 1) = True
rs.MoveNext
Loop
rs.Close
Set rs = Nothing
End Sub
It is a hard feature to test, as the bold dates are only visible in a compiled program, but essentially I must change months then return for the correct dates to be highlighted. Any ideas?
Edit:
If i removefrom my form load event the dates are highlighted as I would expect (with a default value of '1/1/16' in the property page - also struggling to make this value stay when compiling not sure why). If I use 1/11/16 (so this month) I get the same behavior though, incorrect dates highlighted, switch months and switch back and all is well. I have triedCode:dtp.Value = Date
along with various combinations of switching on and off .CalenderDayState and .Refresh in the Form_Load event.Code:Private Sub dtp_DropDown()
Dim tDate As Date
tDate = dtp.Value
dtp.Value = "1/1/2001"
dtp.Value = tDate
End Sub
If appropriate I can create my one thread, but this problem seems so specific to these controls I thought here would be fine...
Update released.
@ Sam_,
the CalenderDayState should work now as expected.
Thanks for reporting.
Hi Krool ... about that bug...
just wondering... do you take into account that when using module (.bas) in an OCX, all "public" variable are SHARED for all instance ?
only variable in the .CTL are not shared (public and private)
I had a similar issue in past with that. I can post you an exemple project that show the bug.
Fantastic, thanks.Quote:
Originally Posted by Krool
Which bug? Please show example.Quote:
Originally Posted by VbNetMatrix
Hi Krool,Why open the mainform vb6 collapse in the IDE?
good question... my previous post didn't post :(Quote:
Originally Posted by Krool
I'll make an example, it's easier to explain.
Hello Krool,
there is a small glitch in the ProgressBar control.
If you change the height by code, a 1px frame is seen around it.
To retrace:
Use the ComCtlsDemo.
In MainForm, set VisualStyles = false for ProgressBar1.
At the end of Form_Load, add:
Now comment out the .Height = 270.Code:With ProgressBar1
.Left = 100
.Top = 600
.Width = 5530
.Height = 270
End With
See the difference?
Karl
P.S.: tested at 125% screen
EDIT2:
While we are at that, a caption property for the progressbar would be nice.
Like in the old old CCRP.
Update released.Quote:
Originally Posted by Karl77
The problem was that normally a ProgressBar will be created with the WS_EX_STATICEDGE style bit.
However, when visual styles are enabled the style bit WS_EX_STATICEDGE is not set on window creation.
That's why this border issue only appears when using a manifest for comctl32.dll version 6.0 or higher and the VisualStyles property is set to False.
The solution was to set or remove the style bit WS_EX_STATICEDGE in the VisualStyles property.
Thanks for reporting.
For the caption property:
Yes, certainly good idea. But there are many ways of how to implement.
I imagine an "inverted" color text for classic theme and for visual theme a theme text within a white box rectangle. (for readability)
Hello Krool,
great, it is fixed now.Quote:
Originally Posted by Krool
In fact I meant it the other way around :-).
The border is not wanted, it makes problems when the control is nested in another control (statusbar in this case).
I'll try to change it myself, now as I know where to look.
Otherwise we would need a Border property...
Let the user decide:Quote:
For the caption property:
Yes, certainly good idea. But there are many ways of how to implement.
I imagine an "inverted" color text for classic theme and for visual theme a theme text within a white box rectangle. (for readability)
TextAutocolor
TextForeColor
TextBackColor
TextBackgroundColor
something like that.
Thank you.
It's difficult to have no border as it's back always when the control size has been changed.Quote:
Originally Posted by Karl77
Speaking of it, can you post a full example on how to use a manifest for comctl32.dll ?Quote:
Originally Posted by Krool
I never succeeded to make it right on Win7
thanks
Just look the Demo..Quote:
Originally Posted by VbNetMatrix
Yes, I experienced this too.Quote:
Originally Posted by Krool
Solution seems to be simple:
EDIT:Code:Public Property Let VisualStyles(ByVal Value As Boolean)
PropVisualStyles = Value
If ProgressBarHandle <> 0 And EnabledVisualStyles() = True Then
Dim dwExStyle As Long, dwExStyleOld As Long
dwExStyle = GetWindowLong(hWnd, GWL_EXSTYLE)
dwExStyleOld = dwExStyle
If PropVisualStyles = True Then
ActivateVisualStyles ProgressBarHandle
If (dwExStyle And WS_EX_STATICEDGE) = WS_EX_STATICEDGE Then dwExStyle = dwExStyle And Not WS_EX_STATICEDGE
Else
RemoveVisualStyles ProgressBarHandle
If Not (dwExStyle And WS_EX_STATICEDGE) = WS_EX_STATICEDGE Then
dwExStyle = dwExStyle And Not WS_EX_STATICEDGE
End If
End If
'If dwExStyle <> dwExStyleOld Then
SetWindowLong ProgressBarHandle, GWL_EXSTYLE, dwExStyle
Call ComCtlsFrameChanged(ProgressBarHandle)
'End If
Me.Refresh
End If
UserControl.PropertyChanged "VisualStyles"
End Property
This is also the place where a Border property could snap to.
What does that solve when resizing?Quote:
Originally Posted by Karl77
You changed the part on RemoveVisualStyles, but there is an error on your change.
Should be:Code:RemoveVisualStyles ProgressBarHandle
If Not (dwExStyle And WS_EX_STATICEDGE) = WS_EX_STATICEDGE Then
dwExStyle = dwExStyle And Not WS_EX_STATICEDGE
End If
As you want no border in both cases.Code:RemoveVisualStyles ProgressBarHandle
If (dwExStyle And WS_EX_STATICEDGE) = WS_EX_STATICEDGE Then
dwExStyle = dwExStyle And Not WS_EX_STATICEDGE
End If
Had a clarifying question - does the new CommandButtonW make any improvements to visual styles/themes? For example, when doing a side by side comparison of the new CommonControls replacement command button vs. the default VB6 style, they look identical. I know there are a lot more features with the new CommandButtonW such as side-by-side captioning, image alignment, split buttons, etc. but is there any change in the actual visual style (e.g., a more modern WinXP or other style upgrade)?
Attachment 142981
Apparently it works, no border comes back on resize.Quote:
Originally Posted by Krool
Try it...
Not exactly, I don't want the border in classic style only.Quote:
As you want no border in both cases.
Karl
The style is given by the OS setting, and the controls use exactly this style.Quote:
Originally Posted by swambast
Nothing less and nothing more.
Karl
Update released.
Critical bugfix in the ListBoxW control. The Click event was not fired in two cases:
- User has de-selected an item in a multiple-selection list box
- User has clicked again on a selected item in a single-selection list box
I'm surprised that this bug did not pop up earlier..
Hi, Krool!
Quiet updated common.bas file(Not seen in the history of changes) - it has new features replaces the standard-VB
There is an error:
FileLen function has always "0" return value.
Yes, thanks for this side note. The common.bas includes also functions not necessary for this project. Therefore I do not add in history of changes when updating.Quote:
Originally Posted by Romeo91
The function FileLen was actually not complete..
I completed the function now and actually improved it. The return value is now as a 'Decimal' Variant. So it can hold unsigned big integer value. (kind of ULONGLONG)
Hi,
did I missed something ?
in post #1
The latest update of ComCtlsDemo.zip (december 7th 2016)
doesn't compile because of missing reference "OLE Guid and interface definition"
"Implements OLEGuids.IOleInPlaceActiveObjectVB" in "IpAdress.ctl"
Do I need any tlb that I doesn't have ?
thanks for your help
From post #1:
It is included in the download.Quote:
At design time (IDE) there is only one dependency. (OLEGuids.tlb)
you're right... when I first installed it, I read everything about the component, now I was at work and tried to download and nothing worked... forgot about it. litle brain, litle brain...Quote:
Originally Posted by chosk
Update released.
Modified the OLEGuids.tlb. (with new uuid)
And sorry for this inconvenience. I know it is a pain in the *** to replace everything, but I couldn't keep it like it is. :D
The IEnumerationVB interface is now removed as not necessary anymore as the Enumeration.cls is event driven since a while. (due to de-coupling issues)
The IEnumeration interface was actually always IEnumVARIANT. But it was named as IEnumeration to not intefere with the stdole.IEnumVARIANT.
But as the IUnknown interface was already named IUnknownUnrestricted to not interfere with the stdole.IUnknown I could also name it likewise to IEnumVARIANTUnrestricted, so I did now. So it is now a clear definition..
And, of course, the correction in IDispatch.GetIDsOfNames was made. (thanks to DEXWERX)
Quote:
Originally Posted by DEXWERX
Thanks for the update to 1.3. It works fine on XP, Win7 and Win10.
HERE is a Script BASIC IDE/Debugger (VB6 app) example.
I hope to be test your library with an OLE interface from Script BASIC to VB6 form controls.
Update
Your COM replacement control works fine when generated as an ActiveX .exe control.
http://www.oxygenbasic.org/forum/ind...ach=5878;image
Update released.
I need to explain a little bit about the recent changes in the ListView control...
The included NewWidth parameter in the ColumnAfterResize event is useful when TrackSizeColumnHeaders property is False, because when ColumnAfterResize is called the new width is not yet applied. So doing ColumnHeader.Width will return the old width.
Also the NewWidth parameter is 'ByRef', which means it can be modified in that event. By that it is possible to define a min/max width for column resizing.
Or to cancel the new width at all, example:
In the 15-Dec-2016 update I included the HDN_DIVIDERDBLCLICK handler in the ColumnBeforeResize event as it effects the width of a column header.Code:Private Sub ListView1_ColumnBeforeResize(ByVal ColumnHeader As LvwColumnHeader, Cancel As Boolean)
ColumnHeader.Tag = ColumnHeader.Width
End Sub
Private Sub ListView1_ColumnAfterResize(ByVal ColumnHeader As LvwColumnHeader, NewWidth As Single)
If [CancelCondition] = True Then NewWidth = ColumnHeader.Tag
End Sub
However, there is no HDN_ENDTRACK fired by HDN_DIVIDERDBLCLICK.
That's why on this update (16-Dec-2016) I isolated HDN_DIVIDERDBLCLICK and included the new event ColumnDividerDblClick, which also has a Cancel parameter.
When the ResizableColumnHeader property is set to False there is no resizing possible at all and also no ColumnBeforeResize nor ColumnDividerDblClick are generated.
I don't get it. You mean generating an ActiveX .exe control? (do you mean .OCX or really .exe ?)Quote:
Originally Posted by ScriptBASIC
The downside for ActiveX .exe is that they don't work with regfree manifest..
The reason I'm using a .exe ActiveX control rather that a .dll version is the .exe version doesn't need to be registered before use. Good to know about the regfree issue. I was just playing around with the idea of using VB forms as controls and interacting with them from Script BASIC but IUP as a cross platform native GUI is the better solution. Using VB to create the IDE is a good example how I plan to us your library in the future.Quote:
I don't get it. You mean generating an ActiveX .exe control? (do you mean .OCX or really .exe ?)
The downside for ActiveX .exe is that they don't work with regfree manifest..
Hi!Quote:
Originally Posted by Krool
Krool, function FileLen still contains an error.
If someone does not see, it can affect its program code
Always - FileLen=0Code:' (VB-Overwrite)
Public Function FileLen(ByVal PathName As String) As Long
Const INVALID_HANDLE_VALUE As Long = (-1)
Const GENERIC_READ As Long = &H80000000, FILE_SHARE_READ As Long = &H1, OPEN_EXISTING As Long = 3, FILE_FLAG_SEQUENTIAL_SCAN As Long = &H8000000
Dim hFile As Long, Length As Double
If Left$(PathName, 2) = "\\" Then PathName = "UNC\" & Mid$(PathName, 3)
hFile = CreateFile(StrPtr("\\?\" & PathName), GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, FILE_FLAG_SEQUENTIAL_SCAN, 0)
If hFile <> INVALID_HANDLE_VALUE Then
Length = GetFileSize(hFile, 0)
CloseHandle hFile
Else
Err.Raise Number:=53, Description:="File not found: '" & PathName & "'"
End If
End Function
You posted the old code. The new returns Decimal Variant. Please re-download and check again.Quote:
Originally Posted by Romeo91
File common.bas in fresh archive (from 17 December 2016) from 5 December.Quote:
Originally Posted by Krool
This code from this file
The Function is expecting a return of FileLen as Long
I think change the line
toCode:Length = GetFileSize(hFile, 0)
Code:FileLen = GetFileSize(hFile, 0)
The function should be like this:
Code:' (VB-Overwrite)
Public Function FileLen(ByVal PathName As String) As Variant
Const INVALID_HANDLE_VALUE As Long = (-1), INVALID_FILE_SIZE As Long = (-1)
Const GENERIC_READ As Long = &H80000000, FILE_SHARE_READ As Long = &H1, OPEN_EXISTING As Long = 3, FILE_FLAG_SEQUENTIAL_SCAN As Long = &H8000000
Dim hFile As Long
If Left$(PathName, 2) = "\\" Then PathName = "UNC\" & Mid$(PathName, 3)
hFile = CreateFile(StrPtr("\\?\" & PathName), GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, FILE_FLAG_SEQUENTIAL_SCAN, 0)
If hFile <> INVALID_HANDLE_VALUE Then
Dim LoDWord As Long, HiDWord As Long, Value As Variant
LoDWord = GetFileSize(hFile, HiDWord)
CloseHandle hFile
If LoDWord <> INVALID_FILE_SIZE Then
If (LoDWord And &H80000000) Then
Value = CDec(LoDWord And &H7FFFFFFF) + CDec(2147483648#)
Else
Value = CDec(LoDWord)
End If
If (HiDWord And &H80000000) Then
HiDWord = HiDWord And &H7FFFFFFF
Value = Value + (CDec(HiDWord) + CDec(2147483648#)) * CDec(4294967296#)
Else
Value = Value + CDec(HiDWord) * CDec(4294967296#)
End If
FileLen = Value
Else
FileLen = Null
End If
Else
Err.Raise Number:=53, Description:="File not found: '" & PathName & "'"
End If
End Function
Was just noticing the columns in the ListView control weren't behaving like my normal setups... would definitely request support for column autosizing.. both the basic LVS_EX_AUTOSIZECOLUMNS style and the LVCOLUMN members you can use with it (cxMin, cxDefault, and cxIdeal)
There is already a AutoSize method in the ColumnHeader, just in case you oversaw it.Quote:
Originally Posted by fafalone
Anyhow, will check your other suggestions soon.
Thanks
LVSCW_AUTOSIZE and LVSCW_AUTOSIZE_USEHEADER are entirely different than LVS_EX_AUTOSIZECOLUMNS, the latter prevents resizing to 0 (exact size is auto adjusted to the presence of image, checkbox, split button or filter too), automatically scales all columns as the ListView is resized both smaller then larger again, and is required to set the minimum width with .cxMin. The Autosize method that's there now just does a single scale operation on a single column when called. They're both useful for sure, just different.
http://i.imgur.com/NXFpqdV.jpg
In this pic, columns 1, 2, and 4 have been resized as small as they're now allowed with the auto-set width. Column 1 has a checkbox and a splitbutton, column 2 just a split button, and column 4 only text. No additional resizing code needed.
http://i.imgur.com/FU4BC7S.jpg
Here the ListView has been resized, and columns 3 and 5 have both been automatically scaled down, no other code involved.
The .cxMin allows setting a min width larger than LVS_EX_AUTOSIZECOLUMNS allows alone.
Hi, Krool. How can I get the VBCCR13.OCX? I am newly registered here in the forum and can't send PMs.
Update released.
As the ResizableColumnHeaders property does not need anymore comctls32.dll version 6.1 or higher to work it is only consistent that also the Resizable property of a ColumnHeader will work when the comctls32.dll version is below 6.1.
The bugfix in the ResizableColumnHeaders was in the 'Get' function.
It returned always True in case the property is not supported. (not supporting = resizable)
But now as the support barrier is gone it must return of course the actual property value.
I sent you a pm.Quote:
Originally Posted by AcidJeff
Thank you very much.Quote:
Originally Posted by Krool
Hi Krool.
Change .Value option on OptionButtonW (also CheckboxW) does not generate a click event.
It is right?
Update released.
Yes, your are right.. Thanks for reporting.Quote:
Originally Posted by Romeo91
This is now fixed, also in the OCX version. Certainly this was the last 'event loophole', hopefully. ;)
Update released.
In this update the mouse events were improved. It concerns the button and shift states for the various mouse events, such as MouseMove.
Before this update the states were retrieved using GetAsyncKeyState.
Now the states are retrieved using the wParam value of the message. (except the ALT shift state, this is retrieved using GetKeyState, not GetAsyncKeyState)
This change might be also a minor performance boost as less API calls are now involved.
However, the main improvement is that the correct button value is now passed in case the left and right mouse button are "swapped" in the windows settings.
How do we download the files? I saw something about PM'ing you but I can click your profile and it does not give a way to PM you.
Also will these fix the problem of trying to use common dialog control in windows 7 in the VB6 IDE... gives a message that I don't have proper licensing to use the control (which makes no sense).
i.e. switch to your replacements and avoid all of the common dialog issues
You can download the Std-EXE version at the first post of this thread. Note that the .z01.zip must be renamed to .z01 before unpacking.Quote:
Originally Posted by torrid33
The licensing issue is of course avoided when using a replacement.
Important update released.
As of this update all key and mouse events are now improved. I recommend to replace all components..
In fact now in all message handlers is now the GetKeyState API used.
(-> GetShiftStateFromParam/GetMouseStateFromParam and GetShiftStateFromMsg/GetMouseStateFromMsg functions)
GetAsyncKeyState is therefore not used anymore.
(-> GetShiftState/GetMouseState function)
The improvement is now that always the "buffered" shift and button state is passed into the events and not the "current" state anymore.
This can be important when the application is unresponsive for some time.
Another important improvement is the "correct" mouse button state when the left and right mouse buttons are swapped in the system settings.
GetKeyState returns always the state of the logical mouse button, whereas GetAsyncKeyState returns the state of the physical mouse button.
Therefore the SM_SWAPBUTTON mapping is only done in the GetShiftState/GetMouseState (GetAsyncKeyState) function and not in the others, for info.
Sorry for the inconvenience caused and the "wrong" handling in the past.
Krool, I've said it before but it's worth repeating. This is truly a phenomenal effort, and I'm continually impressed with your willingness to listen to suggestions for improvements.
Someday, I should attempt to follow your lead and include the MSFLXGRD.OCX and TABCTL32.OCX in this endeavor. The FiexGrid might be a bit of work, as it has some rather complex features. However, the TabControl is nothing but a fancy container that just shifts the controls off to the left when you click the different tabs. Knowing what I know about it, I could probably mock one up pretty quickly using the TabStrip and PictureBox, which you've already done.
Hi Elroy , you have received my private message
Problems sending it will not let me send them, it does not appear to me as sent.
Sorry for disturbing this post
a greeting
A FlexGrid replacement is already in process as said earlier. But will take some time as the first shot should be a complete replacement and quite stable.Quote:
Originally Posted by Elroy
However, that control will fit into this architecture (so the folder can included along the other controls) but will be separated from this here. As the FlexGrid is no "common control" and quite complex.
hi, Krool
I want a copy of the newest version of the VBCCR13.OCX , it is best to bring the source code , thx
you can send me by address : 198838369(please replace with @)163.com
Best Regards
Hi, Krool!
My project Crashes when the program exits from the event Form_KeyDown (Unload Me)
Crashes in IDE and exe-compiled.
If the exit from the program by pressing the cross, all ok.
My project is large, and are also used by other components using subsclassing, but error generate this function
Check please, when will be the timeCode:Public Property Let SubclassEntry(ByVal Entry As Long, ByVal Value As Boolean)
Entry = Entry - 1
Dim EntryPointer As Long
Debug.Assert Entry >= 0 And Entry <= PropVTableCount And VTableHeaderPointer <> 0
If Me.SubclassEntry(Entry + 1) Xor Value Then
EntryPointer = UnsignedAdd(VTableHeaderPointer, Entry * 4)
If Value = True Then
Call CreateSubclass(EntryPointer, vTable(Entry), VTableOld(Entry))
Else
Call CreateSubclass(EntryPointer, VTableOld(Entry), 0)
VTableOld(Entry) = 0
End If
End If
End Property
P.S. https://github.com/ADIAProject/DIA
I cannot replicate this crash in the Demo. Would be too easy of course if it also crashes there on Form_KeyDown. ;-)Quote:
Originally Posted by Romeo91
I did not check your project, maybe you can try to narrow down the cause more on your own. For instance removing some of your other subclasses and so on.
Also it would be a try worth to use the OCX and see what happens there.
Hi Krool.
Small bug in OptionButtonW
If set .value=true for OptionButtonW, when close form and reopen i see that in Gui .value=false (no dot), in options .value=true
Attachment 143731
Fixed. Thank you.Quote:
Originally Posted by Romeo91
Also small bug in CheckBoxW. The Click event was not fired when changing the Value property by code and when the DrawMode is OwnerDraw.
The OCX version was also updated for this bug.
hello Krool, how can I get an "OCX" version of CommonControls (Replacement of the MS common controls) ?