Yes, that works fine now.Quote:
Originally Posted by Krool
Hero!
Karl
Printable View
Yes, that works fine now.Quote:
Originally Posted by Krool
Hero!
Karl
Nit Picking the code base, but your IDispatch.GetIDsOfNames has the wrong definition?
It should be LPWSTR, so you can pass in a BSTR. This way VB skips the Conversion, and you can skip the DoubleUnicode hack you did here.Code:[
uuid(00020400-0000-0000-C000-000000000046),
odl
]
interface IDispatch : IUnknown
{
typedef IDispatch *LPDISPATCH;
HRESULT GetTypeInfoCount([out] LONG *pctInfo);
HRESULT GetTypeInfo([in] LONG itinfo, [in] LONG lcid, [out] LONG *pptinfo);
HRESULT GetIDsOfNames([in] REFIID riid, [in] LPSTR *rgszNames, [in] LONG cNames, [in] LONG lcid, [in, out] LONG *rgDispID);
HRESULT Invoke([in] LONG DispIDMember, [in] REFIID riid, [in] LONG lcid, [in] SHORT wFlags, [in] DISPPARAMS *pdispparams, [in, out] VARIANT *pvarResult, [out] EXCEPINFO *pexcepinfo, [out] LONG *puArgErr);
};
P.S. I definitely appreciate the quality of your code. Regards.Code:Public Function GetDispID(ByVal This As Object, ByRef MethodName As String) As Long
Dim IDispatch As OLEGuids.IDispatch
Dim IID_NULL As OLEGuids.OLECLSID
Set IDispatch = This
IDispatch.GetIDsOfNames IID_NULL, StrConv(MethodName, vbUnicode), 1, 0, GetDispID
'IDispatch.GetIDsOfNames IID_NULL, MethodName, 1, 0, GetDispID
End Function
per our conv. A workaround might be to rename the Typelib, and change it's guid, so new projects use the updated Typelib. Otherwise it may not be worth changing. Thanks for the support.
what is the pager control?
A scrollable container.Quote:
Originally Posted by ishalom
Try the pager demo, see at the start of the thread.
Hello, The RichTextBox Control have a error when is set visible=false.
RichTextBox.Visible=False
The error ocurred when close the execuble.
Try this in Wine. Is more evident in it
Did you call the InitVisualStyles method (from VisualStyles.bas) on startup in your executable?Quote:
Originally Posted by pepegriyo
If this doesn't help please provide a demo showing the error as else I cannot reproduce it.
I know this is dumb question but I have never used color picker dialog box and would like to know how to reference it so can call to be used to change form background etc.
Said it was dumb, sorted it nowQuote:
Originally Posted by jpskiller
Attach a Demo is not working RichTextboxQuote:
Originally Posted by Krool
I Attach Demo2, with completed code.Quote:
Originally Posted by pepegriyo
I've removed your attachments because they contained compiled executables. We do ask that you don't include any compiled components in attachments. It's source code only I'm afraid.
Please feel free to re-attach them but with the executables removed.
Attachment 137625Quote:
Originally Posted by pepegriyo
Update released.
Meaningful when using the DTPicker control.
The Change event was only raised when changing the value by the user.
This behavior is the same in the original MS DTPicker control.
But that behavior makes actually no sense and might be even a bug in the original MS DTPicker control.
On all the other controls the Click/Change (or whatever) events are also raised when changing by code.
So such a behavior is expected and that's why this fix was necessary in my opinion.
Update released.
Again concerning the DTPicker control.
Now it is possible to detect when the checkbox state has changed.
Regardless if it was changed by user or by code.
Could you check my attach?Quote:
Originally Posted by Krool
Something has affected the DTPicker control.
My program uses 12 DTPickers.
4 need to check against one another, eg.
dtpLastDate.Value >= dtpStartDate.Value
dtpStartDate.Value <= dtpLastDate.Value
dtpStartDate.Value >= dtpCurrentDate.Value
dtpLastUpDate.Value <= dtpStartDate.Value
The other 8 are for changing the date to change the ListView info to display.
All 12 DTPicker uses only the Change event. The Click event are not used.
The program boots up in 2 seconds. Now with the new DTPPickers, the program boots up in 17 seconds.
My observation:
When I added these DTPickers into the project on 11-Feb-2014, naturally the Properties automatically show the Value as 11-Feb-2014 and I never need to change that, also I do not need to set any initial default value in the Form_Load. With the 5-May-2016 DTPicker, when the Value is "Change" in codes, something fire that cause errors to show up. This is not the main problem as can be fixed by setting default "Now" values in Form_Load.
The main problem is the extra 15 seconds for the software to boot.
Just notice another problem:
When I click 1 of the 8 DTPicker, the ListView display used to change in less than 2 seconds. Clicking on 1 of the 8 DTPickers synchronizes all 8. Now it take about 13 seconds to change the display.
@ chosk,
That is due to the fact that the change event is now fired when value was changed by code.
You can solve it by placing a "Freeze" variable on your form that is active when synchronizing all 8 DTPickers. At the end reset the variable and update listview. In each DTPicker change event should be a exit sub when the "Freeze" variable is active.
I know that I broke "compatibility". But it was stupid to have not Change event fired when value was changed by code.
I played around with an empty project with just the DTPicker and MsgBox in the Click and Change event handlers. I may have missed the gist of the change.Quote:
Originally Posted by Krool
The Change event was only raised when changing the value by the user.
I now understand this to be when user manually click on the DTPicker and change the date.
I know now the reason for this. I look for a solution..Quote:
Originally Posted by pepegriyo
In the meantime you can do the following as workaround to solve this:
In the Form that contains the invisible RichTextBox call the hidden "IDEStop" method.Code:Private Sub Form_Unload(Cancel As Integer)
RichTextBox1.IDEStop
End Sub
Now the application will close without any error.
Update released.
I have included the ExpandedImage property of a Node in the TreeView control to be more compatible to the original MS control.
Update released.
The first upload of the update today had a bug. I just re-uploaded the update of today.
I saw that 3 users downloaded the first upload..
Please re-download. Sorry..
Update released.
Might be important for those who use the TreeView control.
It is now possible to pass a Node object in the Relative parameter in Nodes.Add and Node.Move.
This is of course possible in the original MS control. This bug should have been detected already..
Anyway, now it's done.
Update released.
Again important for those who use the TreeView control.
It is now ensured that BeforeCollapse/BeforeExpand and Collapse/Expand events are always fired when Expanded property of a Node is being changed.
Prior to this update this was only once fired. (because of TVIS_EXPANDEDONCE)
Also it is now possible to have .Expanded = True even when there are no childs yet. It will be then "actually expanded" when a child is added.
So the behavior is now the same as in the original MS control.
Update released.
This issue is now solved.Quote:
Originally Posted by pepegriyo
The temporary workaround in Form_Unload, that I have suggested for the meantime, is now not needed anymore.
Quote:
Originally Posted by Krool
OK Thank you!! :)
These controls have been a great aid to me in upgrading my app to Unicode support. Thank you for all of your work!
I noticed a rare problem yesterday. The tooltip on a ListBoxW control does not support Unicode. The control does but the tooltip doesn't. I'm using version 1.2
You mean the intrinsic VB ToolTipText property of the control? Yes, sure. No unicode support for that.Quote:
Originally Posted by AAraya
Quote:
Originally Posted by AAraya
The ToolTipText is hardcoded as part of the runtime, so it definitely doesn't support unicode. It is however easy toQuote:
Originally Posted by Krool
do them yourself manually... like in this example.
Thanks for the information. If I'm to be honest, that's a bit disappointing I must say. The other unicode replacement controls I've used in the past support unicode fully - even in the control's tooltip property. I do appreciate your efforts very much however!Quote:
Originally Posted by Krool
Both .NET, and other Non-Free unicode controls use a seperate control to manage ToolTips.Quote:
Originally Posted by AAraya
The VB6 IDE just doesn't support unicode, because the property panel is ANSI only.
Here's a very rough ToolTip class you can modify yourself... you may or may not have to set the font to get it to work properly with east asian languages.
Or you can grab one from elsewhere on this forum.
http://www.vbforums.com/showthread.p...iCode-ToolTips
Code:Option Explicit
Private Const NULL_ As Long = 0&
Private Const HWND_TOPMOST As Long = -1&
Private Const SWP_NOSIZE As Long = &H1&
Private Const SWP_NOMOVE As Long = &H2&
Private Const SWP_NOACTIVATE As Long = &H10&
Private Const CW_USEDEFAULT As Long = &H80000000
Private Const TTF_IDISHWND As Long = &H1&
Private Const TTF_SUBCLASS As Long = &H10&
Private Const TTF_TRACK As Long = &H20&
Private Const TTS_NOPREFIX As Long = &H2&
Private Const TTS_ALWAYSTIP As Long = &H1&
Private Const WS_POPUP As Long = &H80000000
Private Const WS_EX_TOPMOST As Long = &H8&
Private Const WM_USER As Long = &H400&
Private Const TTM_ADDTOOL As Long = (WM_USER + 50&)
Private Const TTM_SETMAXTIPWIDTH As Long = (WM_USER + 24&)
Private Const TOOLTIPS_CLASS As String = "tooltips_class32"
Private Type RECT
Left As Long
Top As Long
Right As Long
Bottom As Long
End Type
Private Type TOOLINFO
cbSize As Long
uFlags As Long
hWnd As Long
uId As Long
Rect_ As RECT
hInst As Long
lpszText As Long
lParam As Long
lpReserved As Long
End Type
Private Declare Function SetWindowPos Lib "user32" (ByVal hWnd As Long, ByVal hWndInsertAfter As Long, ByVal x As Long, ByVal y As Long, ByVal cx As Long, ByVal cy As Long, ByVal uFlags As Long) As Long
Private Declare Function CreateWindowEx Lib "user32" Alias "CreateWindowExW" (ByVal dwExStyle As Long, ByVal lpClassName As Long, ByVal lpWindowName As Long, ByVal dwStyle As Long, ByVal x As Long, ByVal y As Long, ByVal nWidth As Long, ByVal nHeight As Long, ByVal hWndParent As Long, ByVal hMenu As Long, ByVal hInstance As Long, ByRef lpParam As Any) As Long
Private Declare Function DestroyWindow Lib "user32" (ByVal hWnd As Long) As Long
Private Declare Function SendMessage Lib "user32" Alias "SendMessageW" (ByVal hWnd As Long, ByVal Msg As Long, ByVal wParam As Long, lParam As Any) As Long
Private m_hWnd As Long
Private Function CreateTooltipWindow(hWndParent As Long) As Boolean
If m_hWnd Then
CreateTooltipWindow = True
Exit Function
End If
Dim Style As Long
Style = WS_POPUP Or TTS_ALWAYSTIP Or TTS_NOPREFIX
m_hWnd = CreateWindowEx(WS_EX_TOPMOST, StrPtr(TOOLTIPS_CLASS), NULL_, Style, _
CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, _
hWndParent, NULL_, App.hInstance, ByVal NULL_)
If m_hWnd Then
SetWindowPos m_hWnd, HWND_TOPMOST, 0&, 0&, 0&, 0&, SWP_NOMOVE Or SWP_NOSIZE Or SWP_NOACTIVATE
CreateTooltipWindow = True
End If
End Function
Public Function SetToolTip(Control As Control, Caption As String) As Boolean
If Not CreateTooltipWindow(Control.Parent.hWnd) Then Exit Function
Dim ti As TOOLINFO
ti.cbSize = LenB(ti)
ti.hWnd = Control.Parent.hWnd
ti.hInst = App.hInstance
ti.uFlags = TTF_IDISHWND Or TTF_SUBCLASS ' Or TTF_TRACK
ti.uId = Control.hWnd
ti.lpszText = StrPtr(Caption)
SendMessage m_hWnd, TTM_ADDTOOL, 0&, ti
End Function
Private Sub Class_Terminate()
If m_hWnd Then DestroyWindow m_hWnd
End Sub
Here's another Unicode-aware ToolTip class module.
Update released.
The GetFirstVisible function in the TreeView, ListView and ImageCombo control has been removed.
It has been replaced by an improved TopItem property.
Reason is that 'TopItem' is more known/consistent in VB6. (e.g. 'TopIndex' in List and Combo control)
Also note the other improvements. (firing of events when changed by code)
It is not a error that the ItemCheck event in the ListView control is missing in the List, as that event in the ListView control was already fired when changed by code.
Update released.Quote:
Originally Posted by evanzulli
Your request was from 2014...
But hey, now its done. :-)
Update released.
The memory consumption in Report View in the ListView control has been decreased significantly.
Because the handling of the ListSubItems has been improved, which means:
Instead of a collection for each ListItem for the ListSubItems is now an internal array.
This saves one class object per ListItem. And class objects are like big animals. (116 bytes for class object, without content)
Also this internal array allows to have the Tag property of a ListSubItem to be Variant. Before this was very impractical to realize as the properties were saved directly on the Memory Heap.
Attachment 138467
why when i used in winxp have a error
how can i do？thank
I assume you try to use the Groups feature. There are available on Windows XP, but only if the App is linked via manifest to comctl32.dll version 6.0.Quote:
Originally Posted by xxdoc
If you want to keep the IDE on comctl32.dll version 5.8x and only the compiled app linked to 6.0 then use On Error Resume Next while on .Groups.
Hint: In order to trap error raises via "On Error Goto ..." or "On Error Resume Next" it is necessary to have "Break on Unhandled Errors" selected instead of "Break in Class Module" on Tools -> Options... -> General -> Error Trapping.
Concerning the update for the ListSubItems.Quote:
Originally Posted by Krool
Did a bugfix in the Key (String) handling for the ListSubItems method 'Add', 'Item' and 'Remove' in the ListView control.
This minor stupid bug had big impact that the Key accessing did not work at all.
Somehow I didn't notice that yesterday... Sorry.
But hopefully everything should be working now. :)
if i want used one control .i must del other controls,or when i load all controls that is a very big exe.can any good ider?Quote:
Originally Posted by Krool