Printable View
I can't code right now. It's just illustration and not tested. But it should give you the idea.Quote:
Originally Posted by Karl77
Code:With FontCombo1
Do
bDelete = False
For i = 0 To .ListCount - 1
If .List(i) = strExcludeList Then
SendMessage .hWnd, CB_DELETESTRING, i, ByVal 0&
bDelete = True
Exit For
End If
Next i
Loop Until bDelete = False
End With
As an update for any others who may encounter this problem. I replace hundreds of 32-bit icons with 24-bit icons in my app but it did not resolve the problem.Quote:
Originally Posted by AAraya
Three of my users were having this issue. One had Vista and two had Win 7 which had not had all updates installed. When the Windows 7 computer was updated, the VBCCR16 "run-time error 0" issue no longer happens.
Hope this saves someone a bunch of time chasing down other possibilities.
Quote:
Originally Posted by AAraya
What specifically was updated? What changed? Thanks
The Windows 7 OS was updated. No idea exactly which patch(es) resolved this issue. These are end-users, not computer engineers. They didn't go one-by-one, install update, test, install update, test. They just let Windows install all needed OS updates that hadn't been applied yet.Quote:
Originally Posted by DaveInCaz
This is for Krool. Others may want to experiment.
Background: When a DPI-aware project is loaded into non-integral DPI (my own term), 175%, 200%, etc, where VB's twipsPerPixel (TPP) is not the same as the system's (1440 / realDPI) <> VB's TPP, then OCXs have problems. An ocx for simplicity: any control that is not a VB intrinsic control.
Problem: The ocx does not draw into the full width/height of the ocx, it draws smaller than expected. This is directly related to the TPP discrepancy.
Fix when resizing ocxs in this scenario: while sizing, also move the control +1 units Left & Top, then re-move the control -1 units left and top. Though this does address the problem, it still fails when an OCX has an Align property that is set to other than vbAlignNone (zero). You can try with common controls progressbar and set its Align property to non-zero. Again project must be DPI-aware and loaded into 175% DPI or similar non-integral DPI
Ultimate fix is to send the control the dimensions of itself as pixels via an Interface method. That addresses the problem whether the ocx is aligned or not. This requires a bit of low-level API calls, if no TLB for that interface. We would call that interface method each time the form is resized because resizing the form changes the ocx dimensions when Align is non-zero.
Here is some sample code that can be used from the parent/form of an ocx. It should be called from within the Form_Resize event for ocxs that have an Align property set to non-zero.
Now, the above should work in most cases, but can still fail when multiple aligned controls are stacked on each other. Multiple sizing events may occur that undoes the call to SyncOcxClientToParent. In that case, you need a delay. For example, use a disabled timer with a short interval and when Form_Resize kicks off, enable the timer. When the timer kicks off, disable it, and call SyncOcxClientToParent for the affected controls.Code:Private Declare Function DispCallFunc Lib "oleaut32.dll" (ByVal pvInstance As Long, ByVal offsetinVft As Long, ByVal CallConv As Long, ByVal retTYP As Integer, ByVal paCNT As Long, ByVal paTypes As Long, ByVal paValues As Long, ByRef retVAR As Variant) As Long
Private Declare Function IIDFromString Lib "ole32.dll" (ByVal lpsz As Long, ByVal lpiid As Long) As Long
Public Sub SyncOcxClientToParent(theControl As Control)
' This can be called in any DPI, but for for non-intrinsic controls, should always
' be called in non-integral DPI. In that case, external OCXs (not VB
' intrinsic controls) may not render to the full bounds of the control. This method
' attempts to fix that. It should only be called for non-intrinsic controls and
' after the control is sized.
Dim oIUnk As IUnknown, oObj As Object, frm As Form
Dim vParamPtr(0 To 1) As Long, vParamType(0 To 1) As Integer
Dim vRtn As Variant, vParams(0 To 1) As Variant
Dim aData(0 To 3) As Long
Dim hWnd As Long, sm As ScaleModeConstants
Const IID_IOleInPlaceObject = "{00000113-0000-0000-c000-000000000046}"
Const IOIP_SetRects As Long = 28&
On Error Resume Next
Set oObj = theControl.object
If Err Then
Err.Clear
Else
Set frm = theControl.Parent
If Err Then ' applies to forms only
Err.Clear: Set oObj = Nothing
Else
sm = theControl.Container.ScaleMode
If Err Then
Err.Clear: sm = vbTwips
End If
End If
End If
On Error GoTo 0
If oObj Is Nothing Then Exit Sub
IIDFromString StrPtr(IID_IOleInPlaceObject), VarPtr(aData(0))
' set up call to DispCallFunc for querying for IID_IOleInPlaceObject
vParams(0) = VarPtr(aData(0)): vParams(1) = VarPtr(oIUnk)
vParamType(0) = vbLong: vParamType(1) = vbLong
vParamPtr(0) = VarPtr(vParams(0)): vParamPtr(1) = VarPtr(vParams(1))
' does object implement IID_IOleInPlaceObject?
DispCallFunc ObjPtr(oObj), 0&, 4&, vbLong, 2, VarPtr(vParamType(0)), VarPtr(vParamPtr(0)), vRtn
If oIUnk Is Nothing Then
With theControl
.Move .Left + frm.ScaleX(1, vbPixels, sm), .Top + frm.ScaleX(1, vbPixels, sm)
.Move .Left - frm.ScaleX(1, vbPixels, sm), .Top - frm.ScaleX(1, vbPixels, sm)
End With
Else
aData(0) = frm.ScaleX(theControl.Left, sm, vbPixels)
aData(1) = frm.ScaleX(theControl.Top, sm, vbPixels)
aData(2) = aData(0) + frm.ScaleX(theControl.Width, sm, vbPixels)
aData(3) = aData(1) + frm.ScaleX(theControl.Height, sm, vbPixels)
vParams(1) = VarPtr(aData(0))
DispCallFunc ObjPtr(oIUnk), IOIP_SetRects, 4&, vbLong, 2, VarPtr(vParamType(0)), VarPtr(vParamPtr(0)), vRtn
End If
Set oObj = Nothing: Set oIUnk = Nothing: Set frm = Nothing
End Sub
For Krool: The above code is for an external call. I'd imagine you can fix your own CCR controls using the same logic. However, here's some things to consider:
1. That sample code needs the UC's position/dimensions from the container's point of view and translated to pixels relative to the form's client area. Consider using the UC's Extender. You can't use GetWindowRect on the UC.hWnd because it will return the wrong dimensions. Actually, you could but would need to scale it by the difference in VB TPP vs real TPP. But not all UCs have hWnds (windowless).
2. The interface method expects two rectangles. Both are identical, so use the same pointer: VarPtr(udtRect)
3. If you are using TLBs, may want to include IOleInPlaceObject. Doing so should negate the DispCallFunc, IIDFromString calls along with the variables used for those calls.
4. From trial and error. Calling the interface method should be done whenever the control resizes, after it resizes, i.e., trap WM_SIZE if possible. If no subclassing is in play, see if Usercontrol_Resize will be good enough & if not, maybe a timer delay method like described earlier.
Questions? PM me.
Perfect, thank you.Quote:
Originally Posted by Krool
I implemented it in the UC directly.
Response to LaVolpe's post:
As preparation I included now IOleInPlaceObject in the OLEGuids.tlb.
In a second update then all the UC's will be updated. It needs time and to test everything out.
---
PS: The ComCtlsDemo in the thread's first post is now only as .zip and not anymore with .docx extension. This was now possible as the VBForums file size limit has been increas for ZIP to 1,024,000.
Criticial bug for the OLEGuids.tlb.
The recent modification - few hours ago - included interface IOleInPlaceObject.
However, it was defined as:
But should have beenCode:interface IOleInPlaceObject : IUnknown
This is now fixed. If anyone replaced OLEGuids.tlb just recently please do again.Code:interface IOleInPlaceObject : IOleWindow
If not replaced again now it's not an issue "right now" but may become in future an issue.
Sorry for the inconvinience caused.
This seems not to be an issue because when the control moves +1 units Left & Top, then re-move -1 units left and top adresses the issue properly when done within UserControl_Resize.Quote:
Originally Posted by LaVolpe
However, I will consider using IOleInPlaceObject::SetObjectRects as this will move the control once instead of twice. (Small benefit)
Also it looks better, rather a direct fix instead a strange looking workaround.
LaVolpe confirmed it.
To assume VB.Form as control's container is not secure. It could be nested within another UserControl.Quote:
Originally Posted by LaVolpe
I liked the idea to use GetWindowRect and correct accordingly VB TPP vs real TPP. However, as you mention, it's not possible for windowless controls. (e.g. LabelW)
So, I come up with this function below. It seems to work. Can you review/comment and/or confirm?
removed
In this context I noticed that in the DPICorrectionFactor common function was a flaw. It should be:
instead ofCode:Public Function DPICorrectionFactor() As Single
Static Done As Boolean, Value As Single
If Done = False Then
Value = ((96 / DPI_X()) * 15) / Screen.TwipsPerPixelX
Done = True
End If
' Returns exactly 1 when no corrections are required.
DPICorrectionFactor = Value
End Function
So currently the Factor must be divided. Which is odd, because a Factor means by definition always multiplication from a result.Code:Public Function DPICorrectionFactor() As Single
Static Done As Boolean, Value As Single
If Done = False Then
Value = Screen.TwipsPerPixelX / ((96 / DPI_X()) * 15)
Done = True
End If
' Returns exactly 1 when no corrections are required.
DPICorrectionFactor = Value
End Function
I wait a little bit before doing something ..
@Krool, we we're talking about the Align property. A control cannot have it set to other than vbAlignNone if the form is not its container. That is correct, isn't it?
In that code, the form was located to use ScaleX,ScaleY. The scalemode of the control's parent was retrieved from theControl.Container.
And non-integral TPP/DPI only needs to compare the system DPI to the form's TPP, if project is system aware or better. VB can only be loaded into system DPI or virtual 100% DPI.
The fix to sync the object rect is always necessary regardless of Align property. Right?Quote:
Originally Posted by LaVolpe
If the new fix should only be used for <> vbAlignNone than I can keep the current implementation and change nothing? Sounds easier for me..
My attempt was now to get rid of the double resizing and only fix resize once for all cases.
Yes, if (1440 / Screen.TwipsPerPixelX) <> (1440 \ Screen.TwipsPerPixelX)Quote:
Originally Posted by Krool
However, and this may not apply to you, but maybe it does. With Win10, one could load forms into different DPI awareness contexts. This means on one form with your controls can be running in per-monitor awareness, while in another form they run in system awareness and in yet in another they run as unaware. In all three cases VB's TwipsPerPixel values do not change. Those values are set when VB initially loads and do not change for the life of the project. When forms are run in a different awareness than what the project loaded into, it has an affect on UCs/OCXs similar to running @ 175% DPI in some cases. I've just discovered that yesterday and am still trying to understand when/why it happens so it can be addressed. I'll follow up once I know more details.
I understand.Quote:
Originally Posted by LaVolpe
In logic I first need to fix the object rect to an system DPI aware state and the VB TPP vs real TPP bug within UserControl_Resize.
I would skip per monitor awareness in that case.
Then later in another step there could be a DPIMonitorVsSystemScaleFactor(...) which when <> 1 on WM_DPICHANGE_BEFOREPARENT then scale another time object rect accordingly with the current diff factor to system aware state.
Agree?
EDIT: maybe this was too easy thought. What happens when the control resizes again due to .Align? I don't know how the behavior is exactly. Maybe such a DPIMonitorVsSystemScaleFactor needs to be done already also within UserControl_Resize...
It's a messy topic. Something in me tells just stick to system dpi awareness and just don't do a per monitor manifest. :D
Even MS states in their memo about it that it still is in early stages where sometimes mixed-mode dpi awareness is necessary.
So best IMO is to get system dpi aware done properly and don't loose the nerves for per monitor awareness.
I don't find it bad when the OS bitmap stretches system dpi vs monitor dpi the applications. This at least ensures ecerything is in correct physical sizes.
You can always ensure the user has access to graphical items so that they can change the scale if they want to, i.e., ensure fonts and images (that don't change automatically by the API window) are available to the user either via SendMessage and/or public UC properties. That might be a good workaround and allows users to make your control fully DPI aware.
The biggest issue I have right now with per-monitor awareness is that not all API windows may support it. And when they do, is there any guarantee that what isn't scaled now won't be scaled in future versions (backward compatibility). It would also have been nice if Microsoft required WM_DPICHANGED_BEFOREPARENT to return non-zero if it DPI changes are going to be handled by the window.
So I think I got my SyncObjectRectsToContainer now pretty straight forward without any cumbersum calculations.
It now receives the border rect of the parent window where the object's window should be located. IOleInPlaceSite::GetWindowContext
Together with IOleInPlaceObject::SetObjectRects it functions now as a perfect straight forward fix for the VB TPP vs real TPP bug.
Or in other words: Apply the dimensions what the host reports to the client.
Doesn't it look clean the new function? Works for all scenarios.
LaVolpe: I wait your feedback until I release an update. :)Code:Public Sub SyncObjectRectsToContainer(ByVal This As Object)
On Error GoTo CATCH_EXCEPTION
Dim PropOleObject As OLEGuids.IOleObject
Dim PropOleInPlaceObject As OLEGuids.IOleInPlaceObject
Dim PropOleInPlaceSite As OLEGuids.IOleInPlaceSite
Dim PosRect As OLEGuids.OLERECT
Dim ClipRect As OLEGuids.OLERECT
Dim FrameInfo As OLEGuids.OLEINPLACEFRAMEINFO
Set PropOleObject = This
Set PropOleInPlaceObject = This
Set PropOleInPlaceSite = PropOleObject.GetClientSite
PropOleInPlaceSite.GetWindowContext Nothing, Nothing, VarPtr(PosRect), VarPtr(ClipRect), VarPtr(FrameInfo)
PropOleInPlaceObject.SetObjectRects VarPtr(PosRect), VarPtr(ClipRect)
CATCH_EXCEPTION:
End Sub
The question remains. Should this new function be always called to ensrue integrity between host and client dimensions? Or only when DPICorrectionFactor() is <> 1 ? (DPICorrectionFactor is only system DPI; not per monitor)
Don't wait too long for feedback. You are using some interfaces and methods I have never played with. I'm interested in it as it does look like it should be a better option than using ScaleX,ScaleY and trying to get container scalemode, etc, that I was initially using.
BTW, I did figure out in what scenarios mixing DPI awareness within a project would cause the OCX to not size correctly. It isn't just DPIs like 175%. The logic looks like this: If 1440 / GetDpiForSystem <> Screen.TwipsPerPixel. At 175%, 200% DPI, that calculation returns not equal. And when mixed awareness is in play, the calculation appears to work perfectly. When that calculation returns not equal, then sync is needed else is not. This is just FYI for you. I don't know if you plan on calling your new SyncObjectRectsToContainer during every resize or not. Prior to Win8.1, the old calculation will work just fine.
Tip: GetDpiForSystem is for Win10,v1607 or better. Need to use GetProcessAwareness for Win8.1 to Win10 before v1607.
Just saw your edited question. That's kinda tough. Right now, I know of two specific/different scenarios that cause DPICorrectionFactor<>1. Will there be more in future Win10 updates. If your new function does not trigger extra resize events, maybe always call it, else only call it when DPICorrectionFactor<>1.
That's the questions.. Should I just call SyncObjectRectsToContainer on every UserControl_Resize. My feeling says just call it when it's necessary.Quote:
Originally Posted by LaVolpe
But what should be the condition when to call it? So that system DPI user or per Monitor DPI user will be happy and face no issues with the VBCCR.
Krool, I tried your new routine and converted it to TLB-less calls and tested that too. All looks good.
In my tests, I chose only to sync when DPICorrectionFactor<>1 and it worked well.
FYI: I re-ran your CCR project in that other DPI awareness scenario discussed earlier: Started VB in per-monitor & then loaded your test form as DPI unaware. The current method of moving the control twice worked there too. So I think that answers your question -- maybe just sync when DPICorrectionFactor<>1
Update released.
New function SyncObjectRectsToContainer now in place for all controls to support non-integral DPI.
For the end-user is no visible impact. Before it "works" and now it works. However, the number of resizes is reduced a lot for non-integral DPI.
Update released.
Affected are all controls which has a Transparent property and set to True and also the app runs on non-integral DPI. (dpi-aware)
The background most likely is black. A .Refresh fixes this issue but it's unfair when on integral DPI it's not necessary. So the developer is most likely not aware to call .Refresh after load.
Thus now whenever UserControl_Resize is called the transparent background will be updated.
EN_SETEVENTMASK value (although CCR's RichTextBox doesn't use it) is 1073 (&H431) or 1093 (&H445)? I am confused.
Edited: EN_SETEVENTMASK should be 1093. I am confused on some pages by google search.
internal const int EM_SCROLLCARET = (NativeMethods.WM_USER + 49);
internal const int EM_SETEVENTMASK = (NativeMethods.WM_USER + 69);
?Quote:
Originally Posted by DaveDavis
EM_SETEVENTMASK is used already.
Sorry, I missed. CCR used during creation.Quote:
Originally Posted by Krool
I taught EM_SETEVENTMASK can do fast updating. But I have no evidence.
Code:private int updating = 0;
private int oldEventMask = 0;
public void BeginUpdate() //Faster Updating
{
++updating;
if (updating <= 1)
{
const int EM_SETEVENTMASK = 0x445;
const int WM_SETREDRAW = 0xB;
//Prevent the control from raising any events. This message returns the previous event mask.
oldEventMask = SendMessage(new HandleRef(this, base.Handle), EM_SETEVENTMASK, 0, 0);
// Prevent the control from redrawing itself.
SendMessage(new HandleRef(this, base.Handle), WM_SETREDRAW, 0, 0);
}
}
public void EndUpdate()
{
--updating;
if (updating <= 0)
{
const int EM_SETEVENTMASK = 0x445;
const int WM_SETREDRAW = 0xB;
// Allow the control to redraw itself.
SendMessage(new HandleRef(this, base.Handle), WM_SETREDRAW, 1, 0);
// Allow the control to raise event messages.
SendMessage(new HandleRef(this, base.Handle), EM_SETEVENTMASK, 0, oldEventMask);
}
}
So the TabStrip randomly stopped working today. Didn't make any changes to any control-related files. The tabs stopped displaying, and when I try to open the (Custom) property page, I get run-time error 0x80010108 'The object invoked has disconnected from its clients.' at which point VB freezes and has to be killed from a process manager. No idea where this could be coming from. :confused:
I'm using it as a UserControl; added all needed files. It's been stable for years. A frame control also stopped drawing but deleting it and creating a new one fixed that issue; deleting and creating a new TabStrip however did not.
At which spot the error raises?Quote:
Originally Posted by fafalone
Can you encapsulate it in a demo?
It happens when I click the button to bring up the property page of the (Custom) property at the top... couldn't initially tell the exact line because it was frozen, but...
I tried to place one on another form in the same project, and it worked normally.
Then I tried a 3rd form, and it didn't lock up when the run-time error popped up, and the problem is arising in PPTabStripGeneral:
The error is raised on that last line. VB crashes entirely a few seconds later.Code:Private Sub PropertyPage_SelectionChanged()
Dim i As Long
FreezeChanged = True
With PropertyPage.SelectedControls(0)
CheckEnabled.Value = IIf(.Enabled = True, vbChecked, vbUnchecked)
CheckVisualStyles.Value = IIf(.VisualStyles = True, vbChecked, vbUnchecked)
For i = 0 To ComboMousePointer.ListCount - 1
If ComboMousePointer.ItemData(i) = .MousePointer Then
ComboMousePointer.ListIndex = i
Exit For
End If
Next i
If ImageListEnumerated = False Then
Dim ControlEnum As Object
For Each ControlEnum In .ControlsEnum
Edit: I think it's some kind of system condition... like I mentioned the code hadn't changed, and the same problem seems to be happening in backup copies where definitely nothing has changed.
Edit2: Tried to upgrade to the newest version and now nothing works at all. Can't open any old form that had one of the controls on it, placing new controls stops working random (crash), tried to open the ComCtlsDemo.vbp and whenever I go to open one of those forms, app crash (no runtime error, just full-on crash). Unregistered the old version of OLEGuids and registered the new one, so that's not the issue.
Hi Krool ,
In listview control , when I try to read the hint property of a listview group , the IDE crashes . I have downloaded and re-registered the OCX and replaced the OleGUID files to the latest ones but same problem still happens . I tested this in a fresh-downloaded comctlsdemo project and the result was the same .
I tried to read it by index and key but these were not successful
All other properties I have tested for the groups collection are working properly .Code:Msgbox listview1.groups(1).hint ' failed
Msgbox listview1.groups("SomeKey").hint ' failed
Thanks!Quote:
Originally Posted by Hosam AL Dein
It's fixed now.
I've tried different versions and they're all just crashing... all my projects that use these controls are completely unusable now :(
Best I can offer at this point is the call stack leading up to
Exception thrown at 0x770630BD (ntdll.dll) in VB6.EXE: 0xC0000005: Access violation reading location 0x6CE044C7.
770630BD mov cx,word ptr [ecx+10h]Code:> ntdll.dll!_RtlSizeHeap@12() Unknown
AcXtrnal.dll!NS_FaultTolerantHeap::APIHook_RtlFreeHeap(void *,unsigned long,void *) Unknown
kernel32.dll!_HeapFree@12() Unknown
VB6.EXE!0049fc2b() Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for VB6.EXE]
VBA6.DLL!0fc01e3a() Unknown
VBA6.DLL!0fc01dfd() Unknown
VBA6.DLL!0fa91baa() Unknown
VBA6.DLL!0fb48b8f() Unknown
VBA6.DLL!0fa91e09() Unknown
VBA6.DLL!0fc01e3a() Unknown
comctl32.dll!_CallNextSubclassProc@20() Unknown
comctl32.dll!_MasterSubclassProc@16() Unknown
user32.dll!_InternalCallWinProc@20() Unknown
user32.dll!_UserCallWinProcCheckWow@32() Unknown
user32.dll!_SendMessageWorker@24() Unknown
user32.dll!_SendMessageW@16() Unknown
comctl32.dll!_CCSendNotify@12() Unknown
comctl32.dll!CReBar::_ResizeChildren(void) Unknown
comctl32.dll!CReBar::_ResizeNow(void) Unknown
comctl32.dll!CReBar::_Resize(int) Unknown
comctl32.dll!CReBar::_SetBarInfo(struct tagREBARINFO *) Unknown
comctl32.dll!CReBar::_WndProc(struct HWND__ *,unsigned int,unsigned int,long) Unknown
comctl32.dll!CReBar::s_WndProc(struct HWND__ *,unsigned int,unsigned int,long) Unknown
user32.dll!_InternalCallWinProc@20() Unknown
user32.dll!_UserCallWinProcCheckWow@32() Unknown
user32.dll!_SendMessageWorker@24() Unknown
user32.dll!_SendMessageW@16() Unknown
VBA6.DLL!0fc01d67() Unknown
VBA6.DLL!0fc01e3a() Unknown
VBA6.DLL!0fc01826() Unknown
VBA6.DLL!0fc01826() Unknown
VB6.EXE!0047b936() Unknown
VB6.EXE!0047b90f() Unknown
VB6.EXE!0047b700() Unknown
VB6.EXE!00478921() Unknown
VB6.EXE!00403882() Unknown
VB6.EXE!00405bc3() Unknown
user32.dll!_NtUserGetCPD@12() Unknown
user32.dll!_InternalCallWinProc@20() Unknown
user32.dll!_UserCallWinProcCheckWow@32() Unknown
user32.dll!_DispatchMessageWorker@8() Unknown
user32.dll!_DispatchMessageA@4() Unknown
VB6.EXE!0047acce() Unknown
VB6.EXE!0047ac2e() Unknown
MSO97RT.DLL!3078d393() Unknown
MSO97RT.DLL!3078d224() Unknown
VB6.EXE!0047ad57() Unknown
VB6.EXE!004653c3() Unknown
VB6.EXE!00463f5a() Unknown
kernel32.dll!@BaseThreadInitThunk@12() Unknown
ntdll.dll!___RtlUserThreadStart@8() Unknown
ntdll.dll!__RtlUserThreadStart@8() Unknown
Happens whenever I try to view the main form (but not the other forms) in the ComCtlsDemo.vbp project, or any of my projects with most of the controls.
Copied everything to a fresh VM with Win8, the ComCtlsDemo project worked, I opened my other project, it crashed on form load, then ComCtlsDemo also started crashing on form load, this time with error pointing to AcLayers.dll instead of ntdll. Somehow something has happened whereby just viewing a form in my old project completely breaks this project for the entire system and all future projects going forward even if reinstalled, despite not changing a single byte in any project file.
Edit: It might possibly just be something about that form... I recovered it by deleting all controls from this project manually in Notepad, but my project has other forms with the controls and no crashing occurs, but if I even try to create a new one on my main form, boom... needless to say, this is baffling.
As an experiment, I copied all controls to a new form; created a new TabStrip and crashed outright. Created new form, created TabStrip, works normally, paste controls from other form, 'Object has disconnected from clients' runtime error on property page, then crash. (Only controls being copied are pure native VB controls at this point, not even regular common controls)
Thanks for your response Krool ,
In ListView , When I added 30 columns and some list items ( Enough to fill the height space of ListView ) , horizontal scrolling process is too slow and produces much flicker within the control . I have made some tests to get the factors affecting this issue and I trapped some and excluded some more .
I came to a conclusion that this is affected by the number of ListView columns and the VISIBLE ListView items and consequently ListView height ( which can hide or show some populated list items ) .
I was suspicious about if it was the control width or the columns widths are those who causing this lag too as they increase the columns visual space for the control , but found that they are not involved .
I encapsulated a demo by which you can control :
- Number of columns
- Listview height ( Number of visible list items)
- Number of total list items
- ListView Width
- ListView Columns Widths
Actually , the first two factors are those who affect this issue .
Scenario :
- Add 30 columns with say 14 rows . Scroll Horizontally and notice the lag .
- Add 30 columns with say 200 rows . Scroll Horizontally and notice the lag >> Same lag as above with no increase
- Start decreasing the ListView height by 10 % to reduce the number of visible list items and notice the lag >> Scrolling is smoother
- Repeat the last step until there is one or two visible list items >> Almost no lag at all .
- With any of the steps above , ListView width and columns widths don`t affect scrolling smoothly nor laggy .
I switched to windows explorer and watched the listview behavior with about 40 columns horizontal scrolling and this was not an issue and scrolled smoothly .
Demo :
Attachment 171833
Hi fafalone ,Quote:
Originally Posted by fafalone
I faced issues like these for a long time and I fixed them through time by suspicion , experiment and luck nothing else . Because when it comes to sudden IDE crashes I have no clue of what is going on .
I will not provide fixes but rather areas to watch and consider and I am sure you are totally aware of them but you may find them somehow useful .
Considering the Aclayers.dll module crash , I faced this exact error and with the same scenario you provided , as I remember , this module does some graphical manipulations and this explains why comctlsdemo project crashes when you try to view the main form in IDE rather than running the project and showing it in runtime . In both cases it will not show and the IDE will crash .
What fixed this issue for me ?
1 - It was some conflict and bad data in the manifest of VB6 exe and the manifest resource file included in my project .
I have also faced these IDE crash occurrences in earlier time before the manifest issue and these were some mistakes I have been doing :
2 - At every OCX version update , I was not correctly replacing the old one . I did not un-register the previous version or the update file with the same version . So , It was registry issue .When I ran older projects with older versions registered and disk file locations for the OCX conflicted with those found in registry , the project re-registers the old OCX file maybe from the same location as the newer one or even from its original place if it was still kept in place . I mean it was registry issue related to updating the OCX with either new version or same version with a little tweak .
3 - The last thought is that you maybe using something "Globally" in another project which conflicted with VBCCR . Instancing and scopes of Activex COM classes are the items that I would start searching if I was suspecting the last point because I am not close enough to them .
Thanks for your report.Quote:
Originally Posted by Hosam AL Dein
However, I think I can't do something about it.
1. Windows Explorer don't use ListView. There use a direct internal control not exposed to comctl32.dll since Win 7.
2. I have no control over comctl32.dll. I removed NM_CUSTOMDRAW as potential bottle neck and no improvement noticed. So that's not the cause.
3. Microsoft Windows Common Controls 5.0 (COMCTL32.OCX) shows the same lag for their ListView. This OCX is also directly linked to comctl32.dll
I have an idea which I don`t know if it is applicable or not . It is built on some information I have extracted from some testing . If the info is wrong then you may forget about the rest of the post .
Info :
After a scroll operation , the entire control is redrawn . So , while holding down the horizontal scrollbar and start scrolling , the control is redrawn at every change of the scrollbar ( which is DeltaX ) whose minimum value is the small change of the scrollbar .DeltaX value is not always number of many small changes it can be greater than small change as the public method Scroll does . And that`s a good point to build a solution on .
What I have thought about depending on the previous info :
I tried to implement a solution that hides the columns that are not in the visible area of the ListView . >> This failed because of first , there is no property to hide a column . second , I thought that the left property of the column changes while a scroll operation has finished ,which was not true . so , I could not control Visibility depending on the Column Left
In the previous demo I provided , I updated it by adding the following
Code:Private Sub ListView1_AfterScroll(ByVal DeltaX As Single, ByVal DeltaY As Single)
ListView1.Redraw = False
End Sub
to stop redrawing the control and it scrolled very smoothly but surely the control appearance was exploited because it had to be redrawn after the scroll operation has ended . This was the point which made me sure the process uses entire control redrawing .Code:Private Sub ListView1_BeforeScroll(ByVal DeltaX As Single, ByVal DeltaY As Single)
ListView1.Redraw = False
End Sub
I edited the code to the following :
Code:Private Sub ListView1_AfterScroll(ByVal DeltaX As Single, ByVal DeltaY As Single)
Timer1.Enabled = True
End Sub
Code:Private Sub ListView1_BeforeScroll(ByVal DeltaX As Single, ByVal DeltaY As Single)
ListView1.Redraw = False
End Sub
So ,the control will not be redrawn at every change of the scrollbar but rather in one second after the scroll has ended which is the code of Timer1 (Sets the redraw to true and then disables it self) . Of course , this is not an optimal solution but I was just testing the behavior . The result was better and lagging is now discrete and happens every one second .Code:Private Sub Timer1_Timer()
ListView1.Redraw = True
Timer1.Enabled = False
End Sub
I tried to refine the solution by combining mouse_down event of listview to fire the redrawing at one second after the scroll has ended and while the mouse is not down . and this event was not firing with lisview scrollbars (intrinsic behavior as I think) . Also It will not be applicable if the scroll is done automatically by mouse scroll , here the mouse down refinement will not be present .
So , now , my solution has two suggestions based on two points :
1- Redrawing only the columns which appear in the visible width space of the listview ? like the way of Virtual List Items does . And this is changed in every horizontal scroll change .
2- Keep entire control redrawing but firing it after a scrollbar journey ends not during the journey . I mean some event like Scroll_In_Progress . In this event we will not be redrawing the control but will only redraw after the scroll really ends . And the words Really ends here is not meant to be fired at end of a change event of a scroll bar but I think it can be implemented by measuring the silence time of a scroll bar after the first scroll . I mean , now I grabbed the the scrollbar , moving it right and left , this should not fire redrawing until it is not moved and remained still for a specific period of time say 100 ms . the we can say the Journey of scroll really ended and then we can fire the redrawing . This approach is a bit like the public method Scroll of the listview . The control is redrawn after a full DeltaX journey and that`s what I think it should be done .This method summarizes what I mean to say in this suggestion .
3 - Combine both solutions . By replacing the last four words of suggestion 1 and applying the suggestion 2 .
I have attached the previous demo with a timer firing the redrawing after one second of horizontal scrolling process completion and you can notice it is smooth for a second >> lags when redrawing >> smooth for a second >> lags when redrawing >> and so on .
Attachment 171851
When I began using VBCCR I experienced 'unexplainable' crashes as well.Quote:
Originally Posted by fafalone
But I didn't give up...
In some scenarios the IDE failed to write the .frx files correctly.
It took me some time to find out, because the .frm/.bas etc. were identical to the working version.
Check the .frx files.
Just an idea.
VBCCR16 v.1.6.50
VB6SP6
i get the error message 457 - This key is already associated with an element of this collection when i try to change the KEY property of an listview item.
thats what i do to get the error message:
- add a new item with the KEY "test"
- set the KEY property to "TEST"
is this a bug or is the KEY property read only?
update:
i checked your function FChangeKey
i guess the item with the "old" key has to be removed first before you add a new item with the same key but a different upper/lower-case...or?Code:Friend Sub FChangeKey(ByVal Ptr As Long, ByRef OldKey As String, ByVal NewKey As String)
Dim Item As Variant, i As Long
For Each Item In PropListItem
i = i + 1
If ObjPtr(Item) = Ptr Then
If NewKey = vbNullString Then
PropListItem.Add Item
OldKey = vbNullString
Else
PropListItem.Add Item, NewKey
OldKey = NewKey
End If
PropListItem.Remove i
Exit For
End If
Next Item
End Sub
The collection has always been text compare and not binary compare.Quote:
Originally Posted by Mith
So don't change from lower to upper case a key.
Keep for example always in lower case and change key when it's really changed text compare wise only.
Hey
Thanks to MountainMan's documentation, I'm finally starting to use VBCCR, great stuff!
I haven't found documentation nor examples of how the ListView column filter is to be used - how do I get the listview to show only matches once something is typed into the filter? I'm not supposed to manually clear and re-populate the listview, am I?
If I need to be able to edit cells in other columns than the first, should I use vbflxgrd or something else from vbccr?
Filtering ListView needs you to re-populate.Quote:
Originally Posted by OldClock
The best performance is to use VirtualMode in ListView, thus making filtering fast.
For cell editing vbflexgrid is the feature richest variant in my controls. So yes, use then vbflexgrid instead of ListView for complex data represantion (view) and cell edits.
vbflexgrid cell edit allows textbox edit, combobox style edit or custom dialog box edit and many events for data validation etc.
In CmoboBoxW , How Can I draw items manually ? and What is the difference between Fixed and Variable drawing Enums in DrawMode property .
I am asking this question because I - in most cases - use the combo style "List" , which draws a gray background for the combo box , once I changed the DrawMode property , the backcolor I set is what is shown .
My last concern is , If I draw items manually , would this affect some features or other properties ?
Thanks in advance .
Edit 1 :
Another question . what is the property ExtendedUI is intended to do . The only effect I noticed is that : If it is set to true , scrolling the combobox opens the list otherwise , scrolling does not open the list and changes the list index and text of the combobox while the list is not opened or dropped down .
Edit 2 :
I have tested the ItemDraw Event and noticed that it is not fired when the DrawMode property is set to Normal . Thus I thought it would be something to start with . But , I did not get the point of some parameters like ItemAction and ItemState . Or This is not right start point ?