Re: CommonControls (Replacement of the MS common controls)
Update released.
Bugfix in the ImageCombo control.
Changing the Text property of a ComboItem did not work as expected.
The Text when adding a ComboItem is not effected. (of course, else the bug would have been noticed already)
I hope that this was one of the last stupid bugs..
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Darkbob
Quite impressive! The demo still crashes VB6 so that doesn't instill confidence. And I've had zero luck with any of the visual styles and manifest and all that. But using the OCX is fairly simple. Nice easy drop-in replacement for the standard controls. Thanks!
That's the reason people prefer the OCX. You don't have to be a VB expert to use it and deploy normally.
Re: CommonControls (Replacement of the MS common controls)
I have a special problem with RichTextBox.
Until now, I subclassed a textbox, in order to catch WM_CONTEXTMENU and show a custom popup menu. I have a class that does all the dirty work of subclassing and unsubclassing. Basically, it captures this message and it shows the menu.
I tried it with RichTextBox control but it doesn't work as expected. Although it works when pressing the appropriate key on the keyboard (next to the right ctrl), the class doesn't receive the WM_CONTEXTMENU message then right clicking the control.
I looked at the control's subclassing code but I didn't see anywhere any message-consuming statement. Or maybe I missed something.
I considered using the control's ContextMenu event but it would be too much of a hassle to recreate the custom-menu-process just for this control.
BTW, my subclassing method works as is with your textboxes, so it must be something with RichTextBox that prevents the message from arriving.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Cube8
I have a special problem with RichTextBox.
Until now, I subclassed a textbox, in order to catch WM_CONTEXTMENU and show a custom popup menu. I have a class that does all the dirty work of subclassing and unsubclassing. Basically, it captures this message and it shows the menu.
I tried it with RichTextBox control but it doesn't work as expected. Although it works when pressing the appropriate key on the keyboard (next to the right ctrl), the class doesn't receive the WM_CONTEXTMENU message then right clicking the control.
I looked at the control's subclassing code but I didn't see anywhere any message-consuming statement. Or maybe I missed something.
I considered using the control's ContextMenu event but it would be too much of a hassle to recreate the custom-menu-process just for this control.
BTW, my subclassing method works as is with your textboxes, so it must be something with RichTextBox that prevents the message from arriving.
Thanks in advance.
There is no WM_CONTEXTMENU message for the RichTextBox control.
However, there is a 'OLEGetContextMenu' and 'OLEContextMenuClick' event available in my RichTextBox control.
The usage is demonstrated in the ComCtlsDemo project. (RichTextBoxForm.frm)
Re: CommonControls (Replacement of the MS common controls)
There is, since you handle it:
Code:
Private Function WindowProcControl(ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
Select Case wMsg
...
Case WM_VSCROLL, WM_HSCROLL
' The notification codes EN_HSCROLL and EN_VSCROLL are not sent when clicking the scroll bar thumb itself.
If LoWord(wParam) = SB_THUMBTRACK Then RaiseEvent Scroll
Case WM_CONTEXTMENU
If wParam = RichTextBoxHandle Then
Dim P As POINTAPI, Handled As Boolean
P.X = Get_X_lParam(lParam)
P.Y = Get_Y_lParam(lParam)
If P.X > 0 And P.Y > 0 Then
ScreenToClient RichTextBoxHandle, P
RaiseEvent ContextMenu(Handled, UserControl.ScaleX(P.X, vbPixels, vbContainerPosition), UserControl.ScaleY(P.Y, vbPixels, vbContainerPosition))
ElseIf P.X = -1 And P.Y = -1 Then
' If the user types SHIFT + F10 then the X and Y coordinates are -1.
RaiseEvent ContextMenu(Handled, -1, -1)
End If
If Handled = True Then Exit Function
End If
...
End Select
...
End Sub
Also, as I mentioned before, the context-menu-key on the keyboard works fine.
Re: CommonControls (Replacement of the MS common controls)
Update released.
Two bugfixes in the SelPrint and PrintDoc methods in the RichtTextBox control.
1. RightMargin/BottomMargin were added to the printable area instead deducted.
2. The printable area was not converted from device units to twips. (the paper area was not wrong)
The 1. bug was truly my fault (stupid bug again), but the impact was not that critical.
But the 2. bug was critical and I give MSDN the fault for this. (and partially me for not noticing the error)
// Set page rect to physical page size in twips.
fr.rcPage.top = 0;
fr.rcPage.left = 0;
fr.rcPage.right = MulDiv(cxPhys, 1440, GetDeviceCaps(hDC, LOGPIXELSX));
fr.rcPage.bottom = MulDiv(cyPhys, 1440, GetDeviceCaps(hDC, LOGPIXELSY));
// Set the rendering rectangle to the pintable area of the page.
fr.rc.left = cxPhysOffset;
fr.rc.right = cxPhysOffset + cxPhys;
fr.rc.top = cyPhysOffset;
fr.rc.bottom = cyPhysOffset + cyPhys;
When I tested the functionality at beginning I did only a simple tests with some words and this worked of course.
But now I tried to print a real document and wondered that it got wrapped in the middle of the printer page...
So, that's the story, with a happy end now.
The OCX has been updated accordingly.
@ Cube8,
I reviewed the point again with the context-menu.
If EM_SETOLECALLBACK is used in the RichTextBox control then WM_CONTEXTMENU will not be sent.
Instead the other OLE events will be send as described previously.
I just let the WM_CONTEXTMENU handler in for the case the EM_SETOLECALLBACK will not be used.
So if you want to have WM_CONTEXTMENU to be sent then set a comment in Sub CreateRichTextBox: (see red line)
Code:
Dim This As OLEGuids.IRichEditOleCallback
' Set This = RichTextBoxOleCallback
If Not This Is Nothing Then
RichTextBoxIsOleCallback = CBool(SendMessage(RichTextBoxHandle, EM_SETOLECALLBACK, 0, ByVal ObjPtr(This)) <> 0)
Else
RichTextBoxIsOleCallback = False
End If
However, a lot of other functionality will be lost. So I recommend to use the other OLE events to get a context-menu.
Re: CommonControls (Replacement of the MS common controls)
Yes, commenting that statement does the job. Thank you.
I have added a new property OleCallbackEnabled [True (default)/False]. Then, instead of just commenting out this statement, I put an If statement before that one. After changing the property, it calls ReCreateRichTextBox and everything works as expected.
You could merge this small change to the code for cases like mine.
Re: CommonControls (Replacement of the MS common controls)
Again modified the SelPrint and PrintDoc routines in the RichtTextBox control.
It now checks if the passed hDC is a printer or not and acts then differently.
A printer DC will be processed like before and split into pages, if necessary.
But if it is a non-printer DC (e.g. PictureBox.hDC) then it will print only what will fit on the screen. (same behavior like in the MS RichTextBox)
Re: CommonControls (Replacement of the MS common controls)
Hi Krool, amazing stuff! What are your terms of use? LGPL? I'd like to use your controls, especially with your specific permission, in my project www.vb64.com (I'm sure you noticed on the other forum ?) -- a replacement IDE for VB6. With your permission, I'd be very happy to put you at the top of the credits.
Work on it is progressing well and am hoping to release a VBScript editing version as a freebie to whet appetites. Obviously VBScript has no controls and I'd like to look at releasing with it a standard control set, as compiled OCX's, based on yours.
You are obviously a devoted VB6er as I am -- VB6 represented a paradigm shift, and I am determined to bring that paradigm back. I got some stick for making it commercial, but I think that's the only pragmatic way to make it happen, and it protects users as well (see Commercial ). Anyway, the early VBScript version will be free.
www.vb64.com logo courtesy of BadAssTechnologies by permission & with thanks.
on a form, create the EXE along with a .manifest file, compile and run the 'Project1.exe' and close it on my Development machine all is OK.
I copied the 'Project1.exe' and 'Project1.exe.manifest' to a new fresh Windows 7 Ultimate SP1 32bit (virtual Machine) and ran it I got the following message:
"Project1 has stopped working...
check online...
close the program..."
If I add another/extra control other than any of the above list the error does not show anymore!
The attached example is running OK on my development machine but it gives:
Runtime error '0' on the Virtual/Fresh Windows on start up (Project1.exe)
Also with the attached example, I selected and deleted all controls Except CommandButtonW control, compiled and ran on the Fresh Windows and it gave:
Runtime error '50003'
Unexpected error
Again, keep up the great work.
Last edited by labmany; Feb 25th, 2017 at 02:07 PM.
on a form, create the EXE along with a .manifest file, compile and run the 'Project1.exe' and close it on my Development machine all is OK.
I copied the 'Project1.exe' and 'Project1.exe.manifest' to a new fresh Windows 7 Ultimate SP1 32bit (virtual Machine) and ran it I got the following message:
"Project1 has stopped working...
check online...
close the program..."
If I add another/extra control other than any of the above list the error does not show anymore!
The attached example is running OK on my development machine but it gives:
Runtime error '0' on the Virtual/Fresh Windows on start up (Project1.exe)
Also with the attached example, I selected and deleted all controls Except CommandButtonW control, compiled and ran on the Fresh Windows and it gave:
Runtime error '50003'
Unexpected error
Thanks for your report and thus help improving the project.
I did a first test and could resolve the problem when removing all properties (not whole control) from the form1.frm (via Notepad) when there is a reference to "form1.frx".
After that the Project1.exe works fine.
So, the problem is then that something goes corrupt on form1.frx at a certain point. However, I was not yet able to isolate the cause and when it happens.
Re: CommonControls (Replacement of the MS common controls)
Hi, I am trying to use VBCCR14.OCX for my VB6 project to support Unicode. I have registered the .ocx file in windows 10 and attached to the project. All the UI's were created, works fine. But when I move the project into different PC and try to run it, it gives me an error "Error in loading DLL" though I register the .ocx file. Can anyone please help me to solve this problem please?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by nisharamj
Hi, I am trying to use VBCCR14.OCX for my VB6 project to support Unicode. I have registered the .ocx file in windows 10 and attached to the project. All the UI's were created, works fine. But when I move the project into different PC and try to run it, it gives me an error "Error in loading DLL" though I register the .ocx file. Can anyone please help me to solve this problem please?
just a thought, if you are using 64bit windows you need to copy the OCX into "C:\Windows\SysWOW64" not in the system32 folder.
Re: CommonControls (Replacement of the MS common controls)
There is a problem in the CommonDialog.cls concerning the printer dialogs.
In MSComDlg the 'PrinterDefault' property is set to True by default. In my CommonDialog.cls it is not, it is set to False by default.
Instead the CommonDialog.cls will set the application instance printer to the selected one via "Set VB.Printer = ObjPrinter".
This works fine in the StdEXE version. However, in the OCX version it is not working as "Set VB.Printer = ObjPrinter" seems to has no effect..
Of course a solution would be to set 'PrinterDefault' to True then the VB.Printer will be changed accordingly to the new system default printer.
This would then also work via the OCX. (Like in MSComDlg)
So my question is:
Shall I change the default value of 'PrinterDefault' to True? Or only set to True in the OCX and not in the StdEXE version?
Include a 'DeviceName' property in CommonDialog.cls so the app can enum the VB.Printer on his own?
Any other solution?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
...
In MSComDlg the 'PrinterDefault' property is set to True by default. In my CommonDialog.cls it is not, it is set to False by default.
... So my question is:
Shall I change the default value of 'PrinterDefault' to True? Or only set to True in the OCX and not in the StdEXE version?
Include a 'DeviceName' property in CommonDialog.cls so the app can enum the VB.Printer on his own?
Any other solution?
Thanks in advance for any help.
I think set default value of 'PrinterDefault' to True, for both Std-Exe and OCX. I am not sure what need to be done in the codes but the end result should be the default printer is initially shown.
Re: CommonControls (Replacement of the MS common controls)
Update released.
'PrinterDefault' is now initially set to True in the CommonDialog class. (like in the MS CommonDialog)
The statement "Set VB.Printer = ObjPrinter" does have an effect in the OCX. But that change is not accessible from the app. Only in the OCX.
So all the changes (like PaperSize etc.) are saved and re-used in the printer dialog. (of course the CommonDialog must be on Form-Level)
But normally the app does not need to know the chosen PaperSize, it is sufficient if the printer dialog knows it as the app will anyhow print on the .hDC.
The only property the app might be interested is the number of Copies. That is not reflected into the .hDC and not accessible in the OCX. (only Std-EXE Version)
That's why I have now included the Copies property. (like in the MS CommonDialog)
The printer dialog will now read/write to that Copies property instead of the VB.Printer object, so it is accessible when using the OCX version.
Re: CommonControls (Replacement of the MS common controls)
Update released.
So after a series of updates in the CommonDialog class I am now finally happy with the situation.
The VB.Printer object is eliminated in the CommonDialog which will be essential for the next OCX release.
Also the behavior is now the same as in the MS CommonDialog class. (by default)
But the MS CommonDialog class had some limitations.
In the MS CommonDialog class you can only write code to print directly to the VB.Printer object in the app when 'PrinterDefault' is True.
Otherwise ('PrinterDefault' is False) you need to rely on the control's hDC property, but no chance of knowing which printer was selected.
Therefore I have included the PrinterDriver/PrinterName/PrinterPort property which will be set after a printer was selected.
Also included 'PrinterDefaultInit' property which determines if the default or user-selected printer will be initialized. (pre-selected)
The default value of 'PrinterDefaultInit' is True to have the same behavior with the MS CommonDialog. (pre-select always default printer)
So when 'PrinterDefaultInit' is False and the user selected a non-default printer that printer will be pre-selected the next time.
Another limitation was that the MS CommonDialog managed internally the Orientation/PaperSize/Copies/PaperBin, but only exposed the Orientation/Copies property.
My class also exposes the PaperSize/PaperBin property which is very helpful when using the page setup dialog. (or exchange information)
The only remaining "issue" is how to handle the PrintQuality/ColorMode/Duplex.
In the MS CommonDialog they are not managed and thus always the driver's default value is used.
Which is not a bad idea as when a printer color mode is monochrome by default and you want to print (one-time) a color document then the next time it will be monochrome again.
So I am thinking/struggling of how to implement this. Maybe others can give some ideas.
Re: CommonControls (Replacement of the MS common controls)
D'oh, critical bugfix for yesterday update.
The PrinterDriver/PrinterPort was wrongly extracted from the DEVNAMES structure... (wrong use of the .wOffset members)
This caused the PrinterDriver/PrinterPort to be cut/truncated. For instance the PrinterDriver 'winspool' got cut/truncated to 'spool'.
In my testings yesterday this was not shown up as the print dialog however managed to find it.
But now in a pdf printer I found out that it failed.. (PrinterPort got truncated to null) But with the fix today it is now working.
Another improvement done as following:
PrinterDriver/PrinterName/PrinterPort are on default empty. This indicates that the default printer will be initialized.
However, when a default printer was selected then that default printer got set in the PrinterDriver/PrinterName/PrinterPort.
When then the user in the meantime changes the system default printer then next time the print dialog shows up the non-default will be selected and not the default.
The improved solution is now that after user selection the DEVNAMES structure is checked on the wDefault member if it includes the DN_DEFAULTPRN flag.
If so the PrinterDriver/PrinterName/PrinterPort will be set to empty, if not then they will be set.
That means that the app should check on return if the PrinterName is empty (= default) or not (= specific) and act accordingly.
So it could look like this:
Code:
Dim ObjPrinter As VB.Printer
With New CommonDialog
.PrinterDefault = False
.Flags = CdlPDUseDevModeCopiesAndCollate
If .ShowPrinter = True Then
If .PrinterName = vbNullString Then
Set ObjPrinter = VB.Printer ' Default
Else
For Each ObjPrinter In VB.Printers
If ObjPrinter.DeviceName = .PrinterName Then Exit For
Next ObjPrinter
End If
MsgBox ObjPrinter.DeviceName
End If
End With
Re: CommonControls (Replacement of the MS common controls)
Thanks for the reply. I have put the OCX file in "C:\Windows\SysWOW64" and registered it. But still I am getting this DLL error. Project is working in the developing machine without any problem but if the project moves to another machine(same environment), this problem happens.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by nisharamj
Thanks for the reply. I have put the OCX file in "C:\Windows\SysWOW64" and registered it. But still I am getting this DLL error. Project is working in the developing machine without any problem but if the project moves to another machine(same environment), this problem happens.
If you are very sure you have registered the OCX properly in the another machine, then open any VB6 project, or create a new one in the another machine. Then add the OCX into the project by going to "Project/Components..." pull down menu. In the Components dialog that open, select the Controls tab and look for VB Common Controls Replacement 1.4 Library. When you find it, select it and click the Apply button. If it goes smoothly, you have registered it correctly. If you cannot find it, then something went wrong with your registration. You will have to fix the registration to fix the DLL not found error.
When you create a VB6 project with one or more OCX added and want to open this project in other machines, the OCX must be in the same logical path in all your other machines before they can work. Otherwise you have to re-do the Project/Components... again to get the OCX that are in different logical paths, therefore cannot be found by the project.
Re: CommonControls (Replacement of the MS common controls)
Update released.
Included the MouseEnter/MouseLeave event and MouseTrack property in the LabelW control.
Other controls will follow soon with the same enhancements.
The MouseTrack property determines whether mouse events occurs when the mouse pointer enters or leaves the control. (Default is False)
My main focus was to solve first the LabelW control before any other as there is a special difficulty on it as it is a "windowless" control. (TrackMouseEvent function will not work)
In addition there is the problem that the bounding rectangle of the LabelW is not always a simple rectangle, it can be a complex region if it is covered by a shape or image control.
So seems like very difficult to accomplish.. However, the solution is quite easy. (inspired by TimeSoft-Software)
I store the mouse position of the last MouseMove event. In a Timer event there is then the following check:
1. Determine if GetCapture is equal to .ContainerHwnd. (Kind of dragging state, no MouseLeave during that case)
2. Check with WindowFromPoint if mouse cursor is still on .ContainerHwnd. (MouseLeave occurs when different)
3. Check if current mouse position is different than the last known position. If it is, this means that no MouseMove event occured although the cursor has been moved. And that can only be when the mouse pointer is no longer over the control. (MouseLeave occurs)
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Update released.
Included the MouseEnter/MouseLeave event and MouseTrack property in the LabelW control.
This is great. Thank you!
This make using LabelW for Win10 style hamburger menu and pretentious tab buttons (to simulate tabcontrol buttons) for a Win10 look alike UI easier. I don't know whether it is possible to have Tabstop property for LabelW possible. If yes, this will complete the works.
Here is an example on how LabelW can be used using screen shot from the Win10 Money app:
Last edited by chosk; Mar 30th, 2017 at 09:52 AM.
Reason: Add image
Re: CommonControls (Replacement of the MS common controls)
I added this sub to your ComCtlsDemo project....
Code:
Sub SetTabStops(TB As Object)
Dim TabStops() As Long
Dim xx&, yy&
Dim Ret As Long
Dim Stops&
'-----------------------
On Error GoTo Bad
ReDim TabStops(6) As Long
Stops = 7
yy = 12
For xx = 0 To UBound(TabStops)
TabStops(xx) = yy
yy = yy + 12
Next
Ret = SendMessage(TB.hWnd, 203, Stops, TabStops(0)) '203 = &HCB
Exit Sub
'------------------------------------
Bad:
Resume Here
Here:
End Sub
I changed your textboxw1 to multi-line and passed it to that sub. In your demo, it worked perfectly setting 3 space tabs. However, when I added it to my project, VB crashes "Visual basic has stopped working"
Any ideas why it should work in one project and not in another?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by JohnTurnbull
I added this sub to your ComCtlsDemo project....
Code:
Sub SetTabStops(TB As Object)
Dim TabStops() As Long
Dim xx&, yy&
Dim Ret As Long
Dim Stops&
'-----------------------
On Error GoTo Bad
ReDim TabStops(6) As Long
Stops = 7
yy = 12
For xx = 0 To UBound(TabStops)
TabStops(xx) = yy
yy = yy + 12
Next
Ret = SendMessage(TB.hWnd, 203, Stops, TabStops(0)) '203 = &HCB
Exit Sub
'------------------------------------
Bad:
Resume Here
Here:
End Sub
I changed your textboxw1 to multi-line and passed it to that sub. In your demo, it worked perfectly setting 3 space tabs. However, when I added it to my project, VB crashes "Visual basic has stopped working"
Any ideas why it should work in one project and not in another?
i am not sure if I am correct but I think the LB_SETTABSTOPS (= &H192) will work for listbox not for textbox.
Re: CommonControls (Replacement of the MS common controls)
A question to the toolbar:
I have a toolbar with several buttons.
All the buttons have the Style = TbrButtonStyleDefault.
In some place of the code I toggle the values of the buttons, like
Now when I click a button, before any action, I want to get the state as well.
But inside the tlb_All_ButtonClick event, always 0 is seen.
Regardless of the current value.
What can this be, or how can I get the value inside the ButtonClick event?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Karl77
A question to the toolbar:
I have a toolbar with several buttons.
All the buttons have the Style = TbrButtonStyleDefault.
In some place of the code I toggle the values of the buttons, like
Now when I click a button, before any action, I want to get the state as well.
But inside the tlb_All_ButtonClick event, always 0 is seen.
Regardless of the current value.
What can this be, or how can I get the value inside the ButtonClick event?
That it is normal. The behavior is the same as in the original MS ToolBar.
The ButtonClick is fired when the mouse is released, so the button state is unpressed as this moment.
Only when the Style is for instance set to TbrButtonStyleCheck then it remains pressed within the ButtonClick and Value will be TbrButtonValuePressed.
Re: CommonControls (Replacement of the MS common controls)
Hello Krool,
Originally Posted by Krool
That it is normal. The behavior is the same as in the original MS ToolBar.
Ah ok, I didn't test, I didn't expect that this is standard.
when the Style is for instance set to TbrButtonStyleCheck
Yes, that works now.
In the click event the opposite state is seen, the click switches the value before we can get the value.
Interesting, but works reliable.
Re: CommonControls (Replacement of the MS common controls)
Regarding my question whether LabelW can have TabStop. LinkLabel has recently been added the MouseTrack/MouseEnter/MouseLeave property in the 9-April update. It already has the TabStop property. If it can also have Center Alignment in both Vertical and Horizontal, then it can be used for Win10 look-alike GUI.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by chosk
Regarding my question whether LabelW can have TabStop. LinkLabel has recently been added the MouseTrack/MouseEnter/MouseLeave property in the 9-April update. It already has the TabStop property. If it can also have Center Alignment in both Vertical and Horizontal, then it can be used for Win10 look-alike GUI.
TabStop can only be implemented in the LabelW when 'CanGetFocus' is set to True, which I am not going to do as it breaks the sense of the Label control.
The LinkLabel is a different story, but there is no way I can see to have a Center Alignment.
So I guess you need to "manually" center it with line breaks and spaces.