Printable View
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..
The OCX has been updated accordingly.
That's the reason people prefer the OCX. You don't have to be a VB expert to use it and deploy normally.Quote:
Originally Posted by Darkbob
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.Quote:
Originally Posted by Cube8
However, there is a 'OLEGetContextMenu' and 'OLEContextMenuClick' event available in my RichTextBox control.
The usage is demonstrated in the ComCtlsDemo project. (RichTextBoxForm.frm)
There is, since you handle it:
Also, as I mentioned before, the context-menu-key on the keyboard works fine.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
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. :mad: (and partially me for not noticing the error)
MSDN: https://msdn.microsoft.com/de-de/lib...=vs.85%29.aspx
In their code the paper area is converted from device units to twips. But in the printable area they did not convert.
When I tested the functionality at beginning I did only a simple tests with some words and this worked of course. :rolleyes:Code:// 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;
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)
However, a lot of other functionality will be lost. So I recommend to use the other OLE events to get a context-menu.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
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.
Thank you for this wonderful project. :thumb::)
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)
The OCX has been updated accordingly.
I just noticed a few controls called HotKey, CommandLink, Pager What is it? what are these?
also how do you use the Coolbar?
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspxQuote:
Originally Posted by Semke
Coolbar = Rebar.
CommandLink = SysLink
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.
Firstly, keep up the great work.
Secondly, when I place one or more control from the following list:
CommandButtonW
TextBoxW
SpinBox
OptionButtonW
FrameW
CheckBoxW
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.
Thanks for your report and thus help improving the project.Quote:
Originally Posted by labmany
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.
@ labmany,
I have found now the properties which are "corrupt".
When you remove the following lines (marked as red) in the .frm file it will work again:
Maybe the pictures you have loaded and that are then stored in the property bag are not compatible?Code:Begin VBCCR14.ImageList ImageList1
Left = 30
Top = 915
_ExtentX = 1005
_ExtentY = 1005
ImageWidth = 24
ImageHeight = 24
InitListImages = "Form1.frx":02BC
End
[...]
Begin VBCCR14.CommandButtonW CommandButtonW1
Height = 1770
Left = 4350
TabIndex = 2
Top = 2550
Width = 4005
_ExtentX = 7064
_ExtentY = 3122
[...]
Appearance = 0
BackColor = -2147483643
ForeColor = -2147483640
Caption = "Form1.frx":34BA
Picture = "Form1.frx":34E4
SplitButton = -1 'True
DownPicture = "Form1.frx":51BE
End
Please advise...
How can I add an ico in imagelist at run time without using LoadPicture. (Select from 32bit or 24bit layers in ico file)
Krool, Please see my thread (#16):
http://www.vbforums.com/showthread.p...-another-color #16
When I copy the contents of my sample.doc into your RichTextBox, each picture becomes two.
Can you prepare a demo showing the problem?Quote:
Originally Posted by dreammanor
Because with normal .rtf files I see no problems.
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?
Quote:
Originally Posted by nisharamj
just a thought, if you are using 64bit windows you need to copy the OCX into "C:\Windows\SysWOW64" not in the system32 folder.
I have put the sample.rtf in MyRichText7.zip which is in my new thread:Quote:
Originally Posted by Krool
http://www.vbforums.com/showthread.p...43#post5147343
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?
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.Quote:
Originally Posted by Krool
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.
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. :)
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. :rolleyes:
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
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.Quote:
Originally Posted by nisharamj
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.
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)
This is great. Thank you!Quote:
Originally Posted by Krool
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:
Attachment 146263
Just wondering. Does the latest version handle WM_ Settabstops for TextboxW ?
You mean EM_SETTABSTOPS ?Quote:
Originally Posted by JohnTurnbull
No, there is no function or method included in the TextBoxW that sends EM_SETTABSTOPS.
I added this sub to your ComCtlsDemo project....
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"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
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.Quote:
Originally Posted by JohnTurnbull
Not using LB_SETTABSTOPS (= &H192)
Using EM_SETTABSTOPS (= 203)
try using tb.hWndUserControlQuote:
Originally Posted by JohnTurnbull
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
This works ok, the button shows a pressed state.Code:.tlb_All.Buttons("xxx").Value = TbrButtonValuePressed.
I can also get the value of the button, tested with a command button:
Works as well.Code:Debug.Print "PressedState:", tlb_All.Buttons("xxx").Value
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?
Thank you,
Karl
That it is normal. The behavior is the same as in the original MS ToolBar.Quote:
Originally Posted by Karl77
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.
Hello Krool,
Ah ok, I didn't test, I didn't expect that this is standard.Quote:
Originally Posted by Krool
Yes, that works now.Quote:
when the Style is for instance set to TbrButtonStyleCheck
In the click event the opposite state is seen, the click switches the value before we can get the value.
Interesting, but works reliable.
Solved.
Thanks,
Karl
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.Quote:
Originally Posted by chosk
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.
Thanks for the reply.Quote:
Originally Posted by Krool
I wasn't hopeful with the LabelW queston. I was checking the LinkLabel in VS 2017 Form and there is center alignment so I tried my luck. Guess the only way for me now to adopt Win10 GUI is to bite the bullet and go UWP and accept the fact that I can only target Win10 and later.
Thanks anyway.
Update released.
Included the ShowTips property in the CoolBar control and the corresponding ToolTipText property of a Band.
RBS_TOOLTIPS style is not working (according to MSDN "not yet supported"), so it was necessary to create a own internal tool tip control.
The "hot region" for showing the ToolTipText is the caption/icon area in a Band.
This post - http://www.vbforums.com/showthread.p...=1#post5160309 - of mine, in the related ActiveX thread, is with regard to some problems encountered by me while using the RichTextBox control of the 'MS Common Controls Replacement' project. I realised today that there is not much activity in the related ActiveX thread. Hence, I am now re-posting my aforesaid reply-post in this thread, hereunder. Hope thats okay, Krool and others. Kindly please help.
First and foremost, thanks a ton to Krool for this wonderful effort. This is absolutely marvelous and it is pretty exciting to go through the various aspects of this project (Replacement of the MS common controls). Though I am interested in all the controls, as of now, my primary interest is on the RichTexBox. So, I started experimenting with it and I encountered some problems.
I am listing the problems below along with a code snippet to illustrate the problems. Please note that I am new to this forum and this is the first time I am writing here. So, in case I have not followed any protocols related to posting, kindly bear with me and please do guide me for later posts. Also, in case I have understood things completely wrongly about one or more aspects of either the RichTextBox control of this project or of this project itself and that is the reason for me facing the following problems, then kindly correct my understanding and kindly guide me as to what to do to set right the following problems.
Problems:
1. When I set some string (e.g. "a") for a RichTexBox control (say, named 'rtb1') and then compare the text with the same string (i.e. if rtb1.text = "a"), the comparison does not return true. Also, adding some string to the end of 'rtb1' results in characters not present in the string getting added (and displayed). I found that space in the original string was always getting replaced by a character whose Unicode value was U2000 (Decimal - 8192). Same with other characters, as far as I observed. A specific character (say 'a') was always getting replaced by one other specific character.
2. 'Len' and 'Instr' consider "VbCrLf"s fully whereas 'SelStart' and 'Find' ignore the Lf in "VbCrLf"s. Because of this, inconsistencies arise.
The code below illustrates what happens because of the above two problems. It needs a Form with a CommandButton (Command1) and a RichTextBox (named 'rtb1')
Code:Private Sub Command1_Click()
Dim s As String
s = " a " & vbCrLf & vbCrLf & " ab"
rtb1.Text = s
If rtb1.Text = s Then
MsgBox "yes"
End If
MsgBox "Length = " & Len(rtb1.Text) '10 is displayed
rtb1.SelStart = Len(rtb1.Text)
MsgBox "Selstart = " & rtb1.SelStart '8 is displayed
MsgBox "Instr b = " & InStr(rtb1.Text, "b") '10 is displayed
MsgBox "Find b = " & rtb1.Find("b") '7 is displayed
rtb1.Text = rtb1.Text & s 'characters not present in string 's' get added (and displayed)
End Sub
Note-1:
After working on "problem 1" for around 6 hours - to find its cause and a possible solution, I finally set right the problem at my end by introducing a line of code in the following function of 'RichTextBox.ctl'.
Code:Private Function StreamStringOut(ByRef Value As String, ByVal Flags As Long) As Long
I added the following line
after the lineCode:Value = Left$(Value, Len(Value))
in the aforesaid 'StreamStringOut' function.Code:Value = RtfStreamStringOut()
I am not at all suggesting that the inclusion of the above line of code is the right thing to do. I am just mentioning what I did so that it can serve as a tip to Krool or any other member to find out the right thing to be done, eventually.
Note-2:
As of now, I do need VbCrLf in my programs. So, I would be happy if the eventual solution does consider VbCrLf fully so that it is consistent with the behavior of the normal RichTextBox (RICHTX32.OCX component, I mean).
Note-3:
I have tested with the latest version of the ocx control (1.4.11). My system is Windows 7, 64-bit.
A few queries now:
1. The links in the RichTextBox are not clickable. I have to set some property on or off to make them clickable? If so, what is that property? If not, is anything planned for making the links clickable in future?
2. The normal RichTextBox wraps text around even if horizontal scroll bar is set. The RichTextBox of this project wraps text around only when the horizontal scroll bar is not set. Can the RichTextBox of this project also made to wrap text around even if horizontal scroll bar is set?
Thanks.
Update released. (Thanks to softv)
There was indeed an error in the RtfStreamCallbackStringOut and RtfStreamStringIn function in the RichTextBoxBase.bas module.Quote:
Originally Posted by softv
Fix in RtfStreamCallbackStringOut
Fix in RtfStreamStringInCode:ReDim Preserve StreamStringOut(0 To (StreamStringOutUBound + BytesRequested - 1)) As Byte
The Byte array is zero-based so the string was then in fact 11 bytes long for a 5 char (10 bytes) string.Code:ReDim StreamStringIn(0 To (StreamStringInLength - 1)) As Byte
However, Len() still reports 10, but comparison did not return true as 11 bytes vs 10 bytes. That's why your workaround with Value = Left$(Value, Len(Value)) "solved" the issues as it cut of the 1 byte at the end. But now the error is solved at the root cause.
The other issues concerning the 'SelStart' and 'Find' I don't have a solution. I have no influence of what EM_EXGETSEL/EM_EXSETSEL or EM_FINDTEXTEX does.
Krool, I've said it before but I'll say it again. You're INCREDIBLE to maintain this code to the level you do. I maintain substantial pieces of code myself, but I typically get paid for it. It's all GPLv3 open source, but I still get paid for improvements. On the beneficent side, I do try to throw generic chunks of it out onto these forums as often as I can when it seems appropriate.
But what you've done here is truly remarkable.
Best Regards,
Elroy
Just some thoughts regarding the InStr() and Find() not returning same value. Using the exact code 3 posts up and in IDE using the standard RTF ocx (not this project's RTF control), those functions do NOT return the same value. However, Len() and SelStart() do.
I don't know what version VB's standard RTF is, but have read that RTF standards v1 used CrLf (internally) for /par markers and v2 uses Lf (internally). This appears to be the reason for the differences in this project's RTF? And if tested, if you added this text: "0123456789" & vbCrLf, 10 times, Len() should be 10 characters longer than SelStart after SelStart=Len()
Note that when rtf is converted to standard text, /par is converted to CrLf. Am unsophisticated test is setting the control's text to: "a" & vbLF. Len() returns 3 not 2. Hence Len() which works on non-rtf returning more characters than SelStart which works on rtf.
Thanks for your very prompt multiple action (fixing the error at its root and also releasing a new update immediately), Krool. Great!
This project is a phenomenal work, not only because of the complexity involved but for the immense benefit it is providing as well. 1000s of developers must be getting benefited through this work and as a consequence, millions of end-users must be getting benefited too. In that way, what a monumental contribution to the world society!
Well, reg. 'SelStart' and 'Find', I will try to do something similar to what I did for "problem 1". If I succeed, I will share the lines of code here so that, if at all possible, you can give an eventual solution for the issues concerning 'SelStart' and 'Find' also.
I will also try to study more about EM_EXGETSEL/EM_EXSETSEL and EM_FINDTEXTEX.
Thanks.
Actually, I had tested that same code at my end too, with the standard rtf ocx. I tested it again at my end after reading your above observation. Find() returned/returns the expected value (9), which is one lesser than the value (10) returned by InStr(). So, with standard rtf ocx, Find() does work correctly at my end, right? Kindly advise. My richtx32.ocx version is 6.1.97.82.Quote:
Originally Posted by LaVolpe
Thanks.
Hi Kroll,
Congratulations for your effort, first of all!!!
There's no alternative for mscomctl.ocx 64bit and I'm struggling to find a solution for that since Microsoft doesn't seem to care. Could your replacement project be compiled for 64bit?
Thanks and kind regards,
Dan
If you can find a 64bit VB6 compiler, Krool will make it happen!Quote:
Originally Posted by dan_p
Update released.
All internal tooltips are now as top-most. (effects all controls that have a internal tooltip control)
When the tooltip was created by the common control itself it will be changed via SetWindowPos HWND_TOPMOST, otherwise (own tooltip) WS_EX_TOPMOST will be simply added on CreateWindowEx.
I think it is not "unusual" to set the tooltip window as top-most, there are many tutorials/examples that suggest in doing so to ensure that the tooltip will always be shown.
Reason that it could not be displayed would be for example when the form window is set to top-most, then the tooltip is displayed behind it. Now it will display correctly in that scenario.
Label problem:
Place 2 labels on a form, both the same font and fontsize.
1 standard label
1 Krool label
Then execute this:
The labels both appear correct, their width is ok.Code:With Label1
.AutoSize = True
.Caption = "abcdefg"
Debug.Print "Label1: ", .Width
End With
With LabelW1
.AutoSize = True
.Caption = "abcdefg"
Debug.Print "Labelw1: ", .Width
End With
But the widths are different numbers:
Attachment 146881
The width is 71 pixels.
Screen.TwipsPerPixelX is 12.
71 x 12 = 852
Something is wrong so far...
Next effect:
When I execute the code the second time, the width is 852 for both labels.
Thank you,
Karl
When you set a new caption, then in LabelW a UserControl.Refresh is done. The effective autosizing is done in the UserControl_Paint event as there is a hDC available which is necessary for a DrawText DT_CALCRECT.Quote:
Originally Posted by Karl77
However, it seems there is a "lag" from UserControl.Refresh to effective UserControl_Paint, kind of a PostMessage "effect". It is not immediately.
I have no idea for the moment of how to solve it. Of course a "Call UserControl_Paint" instead of "UserControl.Refresh" seems to solve the issue, but actually that is not "allowed", or?
With a windowless control, you need the host to initiate the paint event since it is what sends the UC a clipped hDC to draw on. The delay you are seeing is likely between your Refresh call, VB getting that call, and then deciding when to initialize a paint.Quote:
Originally Posted by Krool
One workaround in this case is to resize the control after setting the caption, when AutoSize is active. If you opt for this, it should be employed in the AutoSize property also when setting it to True.
This should force VB to call a repaint immediately, before your property returns, and the resizing above doesn't matter because your AutoSize will resize the control anyway. Just a thought. Personally, I don't necessarily like using TwipsPerPixelX as the offset because that can be quite large if the container's scalemode is say vbInches. A better approach would be to determine the container's scalemode. TwipsPerPixelX is likely the largest unit which should guarantee a resize. If scalemode was twips and we increased size by just +1, no resize event occurs.Code:Public Property Let Caption(ByVal Value As String)
...
If Me.AutoSize Then
UserControl.Extender.Width = UserControl.Extender.Width + Screen.TwipsPerPixelX \ 2 + 1
Else
Me.Refresh
End If
...
Another workaround is to invalidate the rect of your usercontrol within the host and force a redraw via API. But that may be more difficult for windowless controls than the suggestion above.
Edited: The downside is that when a border is visible, you may see a flash between the resizing. Maybe the Extender left,top should be used in an Invalidate call after all. But you'll have to find the container's hWnd because your control's container could feasibly be another windowless usercontrol (no hWnd to be used with RedrawWindow)
FYI, windowless controls cannot be controls containers per se and this makes ContainerHwnd property always available I guess.Quote:
Originally Posted by LaVolpe
Btw, this project needs a github repo since long time ago (and probably has been suggested numerous times already).
cheers,
</wqw>
Actually, that's the only type of control a windowless control can contain. I'm just not sure (have never tried it) if a VB windowless UC can have the ControlContainer property set to True and be assigned as a container for another windowless control that way. However, while the UC is being designed, this is doable with/without the ControlContainer property. I sure hope my memory is good here; not near a VB box prove myself wrong ;)Quote:
FYI, windowless controls cannot be controls containers per se
Edited: Just a follow up now that I have access to VB again. I created a windowless, transparent, UC and simply placed Krools LabelW inside it & set its backstyle to transparent. When that UC was placed on a form, both the UC & LabelW remained transparent. But your 2nd point appears to 100% valid: The LabelW control reported the UC's container hWnd as its own ContainerHwnd. But, subclassing was a bit messed up in that scenario.
My bad. I thought the point was about control containers (like PictureBox) not UserControls with constituent controls.
cheers,
</wqw>
Update released for the LabelW control. (thanks to Karl77 to bring this issue up)
It got now two internal improvements.
Explanation/Solution:
The first improvement concerns the AutoSize property when the Alignment is <> Left and/or the VerticalAlignment is <> Top.
Now the glitch as can be seen in the screen below will not happen anymore.
Attachment 146933
This was solved by making an "InvalidateRect .ContainerHwnd, RC, 1" after the resizing and reposition of the control, where RC is the old bounding rectangle.
The second improvement concerns also the AutoSize property. Problem was that after property returns the new state is not reflected immediately, because we needed to wait for a UserControl_Paint to occur in order to do the resizing and reposition. (auto sizing)
That issue was solved by modifying the Refresh method as following:
So only when LabelAutoSizeFlag is True the redrawing is done immediately. (and thus the auto sizing)Code:Public Sub Refresh()
If LabelAutoSizeFlag = False Then
UserControl.Refresh
Else
Dim RC As RECT
With UserControl
RC.Left = .ScaleX(.Extender.Left, vbContainerPosition, vbPixels)
RC.Top = .ScaleY(.Extender.Top, vbContainerPosition, vbPixels)
RC.Right = RC.Left + .ScaleWidth
RC.Bottom = RC.Top + .ScaleHeight
InvalidateRect .ContainerHwnd, RC, 1
UpdateWindow .ContainerHwnd
' In UserControl_Paint the bounding rectangle will be invalidated again.
' That's why two times UpdateWindow is necessary.
UpdateWindow .ContainerHwnd
End With
End If
End Sub
And that is necessary to have the new bounding dimensions set before the property returns in order to work with.
However, when LabelAutoSizeFlag is False the normal .Refresh method is used as no immediate redraw is necessary and also not wanted.
Because else when you set 10x Caption in a row it would be redrawn 10x, but with UserControl.Refresh it will be consolidated to 1x redraw, which is common behavior all over to improve performance.
So in fact when you have AutoSize set to True and change the Caption 10x it will be redrawn 10x. But in that special case it is actually wanted because maybe you want to check on each Caption change the resulting Width etc.
Krool thanks for so much hard work.
One little change/addition I made to the
PPImageListImages.CommandInsert routine
to save some user drudgery:
Code:Dim Path As String, FileNames() As String
Dim OpenFileDialog As CommonDialog
Set OpenFileDialog = New CommonDialog
With OpenFileDialog
.Flags = CdlOFNExplorer Or CdlOFNPathMustExist Or CdlOFNFileMustExist Or CdlOFNAllowMultiSelect
.MaxFileSize = .MaxFileSize * 5000
.Filter = "All Picture Files|*.ICO;*.CUR;*.BMP;*.GIF;*.JPG|Icons & Cursors (*.ICO;*.CUR)|*.ICO;*.CUR|Bitmaps (*.BMP;*.DIB)|*.BMP;*.DIB|GIF Images (*.GIF)|*.GIF|JPEG Images (*.JPG)|*.JPG|All Files (*.*)|*.*"
.DialogTitle = "Select Picture"
.InitDir = GetSetting("VBCCR14", "ImageList", "File", App.Path)
End With
If OpenFileDialog.ShowOpen = True Then
With OpenFileDialog
If InStr(.FileName, vbNullChar) <> 0 Then
Path = Left$(.FileName, .FileOffset - 1)
If Not Right$(Path, 1) = "\" Then Path = Path & "\"
FileNames() = Split(Mid$(.FileName, .FileOffset + 1), vbNullChar)
Else
Path = Left$(.FileName, .FileOffset)
ReDim FileNames(0) As String
FileNames(0) = .FileTitle
End If
End With
If Not Path = vbNullString Then
SaveSetting "VBCCR14", "ImageList", "File", Path
is there a way to manipulate the width of the combo/list box scrollbar?
not sure this is the right place for this question, but it would sure be a very useful addition to the controls.
thanks