-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Eduardo-
There is a bug in the LabelW control in the DoAutoSize procedure.
The line:
Code:
.Extender.Move .Extender.Left, .Extender.Top, .ScaleX((CalcRect.Right - CalcRect.Left) + (BorderWidth * 2), vbPixels, vbContainerSize), .ScaleY((CalcRect.Bottom - CalcRect.Top) + (BorderHeight * 2), vbPixels, vbContainerSize)
Should be changed to:
Code:
If PropWordWrap = True Then
.Extender.Move .Extender.Left, .Extender.Top, .Extender.Width, .ScaleY((CalcRect.Bottom - CalcRect.Top) + (BorderHeight * 2), vbPixels, vbContainerSize)
Else
.Extender.Move .Extender.Left, .Extender.Top, .ScaleX((CalcRect.Right - CalcRect.Left) + (BorderWidth * 2), vbPixels, vbContainerSize), .ScaleY((CalcRect.Bottom - CalcRect.Top) + (BorderHeight * 2), vbPixels, vbContainerSize)
End If
Hi Eduardo,
I updated yesterday your suggested bugfix. However, I think the behavior is now not really correct.
E.g. make a LabelW1.Caption = "test" with a Width of 255 and WordWrap = True and AutoSize = True.
Now change the Caption to "test_added". The VB.Label autosize the width while now the LabelW doesn't.
My proposed solution would be:
Code:
If PropWordWrap = True Then
.Extender.Height = .ScaleY((CalcRect.Bottom - CalcRect.Top) + (BorderHeight * 2), vbPixels, vbContainerSize)
If .ScaleWidth < ((CalcRect.Right - CalcRect.Left) + (BorderWidth * 2)) Then .Extender.Width = .ScaleX((CalcRect.Right - CalcRect.Left) + (BorderWidth * 2), vbPixels, vbContainerSize)
Else
.Extender.Move .Extender.Left, .Extender.Top, .ScaleX((CalcRect.Right - CalcRect.Left) + (BorderWidth * 2), vbPixels, vbContainerSize), .ScaleY((CalcRect.Bottom - CalcRect.Top) + (BorderHeight * 2), vbPixels, vbContainerSize)
End If
Can you confirm before I update another bugfix?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
Hi Eduardo,
I updated yesterday your suggested bugfix. However, I think the behavior is now not really correct.
E.g. make a LabelW1.Caption = "test" with a Width of 255 and WordWrap = True and AutoSize = True.
Now change the Caption to "test_added". The VB.Label autosize the width while now the LabelW doesn't.
My proposed solution would be:
Code:
If PropWordWrap = True Then
.Extender.Height = .ScaleY((CalcRect.Bottom - CalcRect.Top) + (BorderHeight * 2), vbPixels, vbContainerSize)
If .ScaleWidth < ((CalcRect.Right - CalcRect.Left) + (BorderWidth * 2)) Then .Extender.Width = .ScaleX((CalcRect.Right - CalcRect.Left) + (BorderWidth * 2), vbPixels, vbContainerSize)
Else
.Extender.Move .Extender.Left, .Extender.Top, .ScaleX((CalcRect.Right - CalcRect.Left) + (BorderWidth * 2), vbPixels, vbContainerSize), .ScaleY((CalcRect.Bottom - CalcRect.Top) + (BorderHeight * 2), vbPixels, vbContainerSize)
End If
Can you confirm before I update another bugfix?
Yes, you are right. When its width is smaller than any of the individual words, it extends the width to that.
I performed some testing with your new code and it seems to make it work as the original.
-
Re: CommonControls (Replacement of the MS common controls)
Update released.
Thanks Eduardo.
I fiddled also now again a while with the LabelW AutoSize in comparison to VB.Label with the WordWrap and my previously suggested version works in all scenarios. (slightly modified to cause only 1 resize)
Code:
If PropWordWrap = True Then
If .ScaleWidth < ((CalcRect.Right - CalcRect.Left) + (BorderWidth * 2)) Then
.Extender.Move .Extender.Left, .Extender.Top, .ScaleX((CalcRect.Right - CalcRect.Left) + (BorderWidth * 2), vbPixels, vbContainerSize), .ScaleY((CalcRect.Bottom - CalcRect.Top) + (BorderHeight * 2), vbPixels, vbContainerSize)
Else
.Extender.Height = .ScaleY((CalcRect.Bottom - CalcRect.Top) + (BorderHeight * 2), vbPixels, vbContainerSize)
End If
Else
.Extender.Move .Extender.Left, .Extender.Top, .ScaleX((CalcRect.Right - CalcRect.Left) + (BorderWidth * 2), vbPixels, vbContainerSize), .ScaleY((CalcRect.Bottom - CalcRect.Top) + (BorderHeight * 2), vbPixels, vbContainerSize)
End If
-
Re: CommonControls (Replacement of the MS common controls)
-
Re: CommonControls (Replacement of the MS common controls)
Latest ComCtlsDemo.zip of 20/20/2020 can't start (F5 or Ctrl-F5) and throws the error "To use this functionality, you must provide a manifest specifying comctl32.dll version 6.0 or higher." Note that I have the themes service on XP machine disable because I don't use any theme. How to add the manifest in the project to be able to step through?
Although It makes the exe form the make File->Make ComCtlsDemo.exe and all the controls appear to work the RichTextBox Demo button just ends (or crash) the executable without any clue. The OLEGuids are in system32.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
travma
Latest ComCtlsDemo.zip of 20/20/2020 can't start (F5 or Ctrl-F5) and throws the error "To use this functionality, you must provide a manifest specifying comctl32.dll version 6.0 or higher." Note that I have the themes service on XP machine disable because I don't use any theme. How to add the manifest in the project to be able to step through?
Although It makes the exe form the make File->Make ComCtlsDemo.exe and all the controls appear to work the RichTextBox Demo button just ends (or crash) the executable without any clue. The OLEGuids are in system32.
If youwould read the notes in the first thread you would know to make following setting;
Goto menu Tools -> Options... -> General -> Error Trapping.
"Break on Unhandled Errors" should be selected instead of "Break in Class Module".
This is some odd default setting of VB6 which I can't do something about. However, it's a one-time change in settings and then OK for the end of life of that installation.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Hosam AL Dein
I hope I could make it clear for you as English is not my first language
Your post was far clearer than any of the other posts from the experts. I think you speak well in my native tongue - nOOb! :)
Thanks very much again for your help!
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
travma
Latest ComCtlsDemo.zip of 20/20/2020 can't start (F5 or Ctrl-F5) and throws the error "To use this functionality, you must provide a manifest specifying comctl32.dll version 6.0 or higher." Note that I have the themes service on XP machine disable because I don't use any theme. How to add the manifest in the project to be able to step through?
Although It makes the exe form the make File->Make ComCtlsDemo.exe and all the controls appear to work the RichTextBox Demo button just ends (or crash) the executable without any clue. The OLEGuids are in system32.
You ran into the same problem I found. The demo simply doesn't work. But don't give up - it's a great project and you CAN make it run. There are a bunch of steps you need to take to get it working but the most important is to put a manifest right inside the VB6.EXE. You would think they would maybe mention that somewhere in bold letters in the first post wouldn't you? The details are buried deep in this thread if you dig hard enough. Take a look at posts on Page 64 by Hosam AL Dein.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Darkbob
You ran into the same problem I found. The demo simply doesn't work. But don't give up - it's a great project and you CAN make it run. There are a bunch of steps you need to take to get it working but the most important is to put a manifest right inside the VB6.EXE. You would think they would maybe mention that somewhere in bold letters in the first post wouldn't you? The details are buried deep in this thread if you dig hard enough. Take a look at posts on Page 64 by Hosam AL Dein.
On searching to resolve the "manifest thing" I add a manifest to the vb.exe with some manifester tool I had found there but then again the "manifest error" doesn't go away and because I didn't think that it was relevant to VB options I was never go to change that option mention in the 1st post. Now, thanks to Krool it was resolved, and I guess that I need to carefully look here again to find out why the error 383 on Form_load event raised on FontCombo1.Text = RichTextBox1.SelFontName which VB complain is "Property is read only" when I hit the RichTextBox Demo button. Anyway I never use the RichTextBox. I was searching on listview thinking that control has multiline/wrap ability (vbCrLf kind of stuff) when I realize the listbox and later listview doesn't have that feature and the rows are always one-liners only.
Any help to that matter is welcome as the code structure will stay as intended eg. loop to fill listview with multi-line text in its rows. The single textbox (which seems the only option for me now) doesn't need to attach to a loop to fill with stuff, as the user can click inside another listbox\listview control to see his selection "magnified" in this textbox. But this click-to-see user experience is not what I think.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
dseaman
If you sort your controls alphanumeric in the Vbp file they will appear sorted in the ToolBox.
Actually, I usually sort the entire block containing Modules/Classes/Controls/PropertyPages to make the Vbp more readable.
Makes sense. Thanks.
I sorted now the vbp file for the ComCtlsDemo. The next VBCCR17 will be then sorted likewise.
-
Re: CommonControls (Replacement of the MS common controls)
With today's update the sync between Std-EXE and OCX version is broken.
It's intended to be. It's necessary to fix some problems and also an opportunity to include new features or to solve deficits.
So when somebody has a wish, now it's the time.
The idea is to bring everything in order so in a few weeks/months VBCCR17 can be released.
Also then when a (maybe final?) VBCCR17 is then released I could spent some time to make a documentation..
-
Re: CommonControls (Replacement of the MS common controls)
Vertical Slider that will truly reverse.
---------
Also, I've been neglecting to bring this up because it'd probably take quite a bit to isolate the problem, but I'm having some kind of a timing issue. Also, it's probably not a problem in the OCX version, but I don't know, as I've got your Slider, TreeView, and StatusBar source code just included in my project.
But basically, under some strange circumstances, it's cycling through the certain controls on a form, causing them to fire GotFocus and LostFocus events, which was giving me a big problem. It's happening after certain forms get loaded, and even after the completion of my Sub Main procedure ... but before the user actually does anything. In other words, it's as if something about the VBCCR is "settling down" and firing those GotFocus and LostFocus events.
The control that was giving me the most problem was NOT the first of the TabIndex order. I checked that thoroughly. I also checked to make sure that nothing I did was setting the focus of that control, and nothing is. And it's definitely before the user does anything. I'll admit that I didn't check to see if it was both a compiled and IDE problem. I was getting the problem in the IDE (while running) ... no problems in design mode. Also, just as a further FYI, as I jiggle the design of the form, the problem control moves around to different controls.
Here's how I fixed it. First, I created a global variable:
Code:
Public gbStarting As Boolean ' Just used during program startup to give a few milliseconds to let things settle down.
And then, I put my own timer on the primary form. I pre-set it to Enabled=True and Interval=500.
And then, I put this in the timer's event, which just executes once:
Code:
Private Sub TimerStartup_Timer()
' This just fixes some weird startup thing where a random control gets the focus, which may mess things up.
' I believe it has something to do with Krool's controls.
'
TimerStartup.Enabled = False
gbStarting = False
End Sub
And then, in a few critical places, I checked the gbStarting global, and just did an Exit Sub if it was true.
Without releasing the thread, I couldn't find a way to solve the problem. Also, just as a further FYI, I tried tracing back from the GotFocus event, and it immediately went into some of your code in the ComCtlsBase.bas module. Let me turn off the timer and see if I can get the error again. ... Well drat, I can't reproduce it at the moment. That was quite a few versions back (of MY program) that I was getting it and implemented that above fix.
Other than deleting the property pages in the Slider, TreeView, and StatusBar controls, I'm using your code perfectly unchanged. I've got the following modules of yours in my project:
- ISubclass.cls
- Common.bas
- ComCtlsBase.bas
- VisualStyles.bas
- VTableHandle.bas
- Slider.ctl/ctx
- StatusBar.ctl/ctx
- TreeView.ctl/ctx
- TvwNode.cls
- TvwNodes.cls
- SbrPanel.cls
- SbrPanels.cls
- SbrPanelProperties.cls
-----
I'm good, but, since you asked for stuff, I thought I'd outline it for you.
Elroy
-
Re: CommonControls (Replacement of the MS common controls)
Krool,
Is it time to fold VBFlexGrid into the forthcoming VBCCR17?
-
Re: CommonControls (Replacement of the MS common controls)
Krool, as per my previous request, which I think you haven't yet seen...
http://www.vbforums.com/showthread.p...=1#post5453057
Add Horiz. & Vert. Skroolbars to the CommonControls Collection
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
So when somebody has a wish, now it's the time.
Not easy to enhance a perfect thing!
Unsorted and perhaps unrealistic:
-a- unified tooltip appearance
-b- full control over the colors in order to get a dark mode
-c- a menu control that can show icons
-d- all existing controls with a horizontal scrollbar shall react to the wheel when mouse is over it
To a:
AFAIK in the works from time time.
To b:
I know comctl32 doesn't offer a dark mode.
Maybe it is somehow possible anyway?
To c:
I know there are some solutions around.
And I use one of them, but it's cumbersome to work with it.
Not nearly the quality as VBCCR.
To d:
Paint.net has this feature, and I think it is a clever idea.
My $0.02
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
yereverluvinuncleber
I read it but ignored it. There are 2 types of scrollbars.
1. Encapsulated with in an independent hWnd
2. Embedded in a control, same hWnd as control. (NC area)
So making a type 1 scrollbar like VB.scrollbar won't make a difference without hooks/subclasses.
And my aim is to avoid hooks whereever possible and not to subclass "beyond the UC border".
So the answer tends to say: no.
Quote:
Originally Posted by
MountainMan
Is it time to fold VBFlexGrid into the forthcoming VBCCR17?
Think not. The VBFlexGrid might be developed further after VBCCR17. When it's separated then the development can be independent.
-
2 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
How do you repaint a CommandButtonW's picture with a vertical offset?
Before using VBCCR, I made custom graphical buttons by creating a PictureBox (which I call PictureBtn), setting PictureBox.Picture to a GIF, and setting the size of the PictureBox to half the height of the GIF. The GIF contains two versions of an image stacked vertically: the top one is the image in a normal state, and the bottom one is a darker version of itself. The idea is that when you hover the mouse over the button, the picture changes to the darker version, to convey the hover effect.
Attachment 174899
To do that, on PictureBox_MouseMove I would PaintPicture with the vertical offset Y1 set to -128, but there is no MouseLeave event for the PictureBox so I would work around that by using Frame_MouseMove and PaintPicture with the PictureBox's vertical offset Y1 set to 0:
Code:
Private Sub PictureBtn_MouseMove(Index As Integer, Button As Integer, Shift As Integer, x As Single, y As Single)
PictureBtn(Index).PaintPicture PictureBtn(Index).Picture, 0, -128
End Sub
Private Sub Frame_MouseMove(Index As Integer, Button As Integer, Shift As Integer, x As Single, y As Single)
Dim pb As PictureBox
For Each pb In PictureBtn
pb.PaintPicture pb.Picture, 0, 0
Next
End Sub
But using Frame_MouseMove is unreliable, since the mouse might not move onto the frame but onto some other control.
VBCCR's CommandButtonW has the MouseEnter and MouseLeave events, great. I created a CommandButtonW with Style=vbButtonGraphical and the Picture set to the same GIF as above. However, the picture is centered vertically, so this is what I see:
Attachment 174901
I tried changing CommandButtonW.VerticalAlignment but it seems to have no effect on the picture or on the caption.
Using Windows XP SP3.
How do I repaint the picture with Y=0, and with Y=-128?
I see there is CommandButtonW.Picture.Render but no luck figuring out how to use that yet.
-
Re: CommonControls (Replacement of the MS common controls)
Well, I managed to redraw the picture using this:
Code:
Private Sub RoundButtons_MouseEnter(Index As Integer)
With RoundButtons(Index).Picture
.Render GetDC(RoundButtons(Index).hwnd), 0, 0, 128, 256, _
0, .Height / 2, .Width, -.Height, 0
End With
End Sub
Private Sub RoundButtons_MouseLeave(Index As Integer)
With RoundButtons(Index).Picture
.Render GetDC(RoundButtons(Index).hwnd), 0, 0, 128, 256, _
0&, .Height, .Width, -.Height, ByVal 0&
End With
End Sub
However, the picture is still vertically centered (i.e. looks wrong) when the form is loaded, and only gets "fixed" once I mouse-over. I tried calling the RoundButtons_MouseLeave routine to re-render the picture from Form_Activate (it's an MDI child form) but when the form appears the button is still wrong. I tried calling it from Form_Paint, but for some reason the form paint event never fires. And even if I mouse-over the button (which makes it look correct, the picture gets set to y=0), then it gets re-centered (i.e. broken) if I switch to a different window and then switch back to my program.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
OldClock
How do you repaint a CommandButtonW's picture with a vertical offset?
Why making it so complicated? And why this problem should be solved in CommandButtonW? Next time somebody comes with an horizontal offset, or diagonal...
Instead use a paint program and split your picture in two pieces and put the normal picture in PictureBox1 and the hover picture in PictureBox2 and just make:
Code:
Private Sub CommandButtonW1_MouseEnter()
Set CommandButtonW1.Picture = Picture1.Picture
End Sub
Private Sub CommandButtonW1_MouseLeave()
Set CommandButtonW1.Picture = Picture2.Picture
End Sub
-
Re: CommonControls (Replacement of the MS common controls)
TreeView control is now 'Alignable'.
This enables it now to be placed on MDIForms, for example as a 'menu tree' style control.
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
I download and started ComCtlsDemo and I get:
Attachment 174913
so I can't do much. it freezes the IDE and I need to hard-close the IDE.
https://i.postimg.cc/28VKdRKd/Image1.png
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
baka
Overwrite with new OLEGuids.tlb.
-
Re: CommonControls (Replacement of the MS common controls)
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
baka
Did you replace the file in SysWOW64 folder? (or System32)
-
Re: CommonControls (Replacement of the MS common controls)
Thanks for your effort
I'm using your CommonDialog and maybe there is an issue easy to solve but...
Option Explicit
Public myPrinter As Printer ' initialized in app.main
Public Sub SetMyPrinter()
With New CommonDialog
.CancelError = False
.PrinterDefault = False
.PrinterDefaultInit = False
.PrinterName = myPrinter.DeviceName
.PrinterPort = myPrinter.Port
.PrinterDriver = myPrinter.DriverName
If .ShowPrinter Then
If Len(.PrinterName) = 0 Then
' if the default printer was selected Krool's CommonDialog returns true but printer parms are not set
' Using the Printer object solves this issue
Set myPrinter = Printer
Else
Dim objPrinter As Printer
For Each objPrinter In Printers
If objPrinter.DeviceName = .PrinterName Then
Set myPrinter = objPrinter
Exit For
End If
Next
End If
End If
End With
End Sub
If the default printer was selected CommonDialog returns true but printer parms are not set
Is this the way it works?
Or maybe the following:
If ((DNAMES.wDefault And DN_DEFAULTPRN) = 0) Then
should be:
If ((DNAMES.wDefault And DN_DEFAULTPRN) = 0) Or (PropPrinterDefaultInit = False) Then
or better:
Dim bReq As Byte
If (PDLG.Flags And CdlPDReturnDefault) = 0 Then
bReq = PropPrinterDefaultInit = False And Not (PropPrinterDriver = vbNullString Or PropPrinterName = vbNullString _
Or PropPrinterPort = vbNullString)
If ((DNAMES.wDefault And DN_DEFAULTPRN) = 0) Or bReq Then
QUESTION:
Is it possible to use CommonDialog as above and skip User input like when PropFlags = CdlPDReturnDefault
-
Re: CommonControls (Replacement of the MS common controls)
Update released. (VBCCR16.OCX also updated on this)
Quote:
Originally Posted by
Simos
If the default printer was selected CommonDialog returns true but printer parms are not set
I always use CdlPDReturnDC so this didn't bother me yet.
Also the MS Common Dialog doesn't provide such functionality, so there is no "comparable behavior" to consider.
The idea was: if the params return null then the default printer was selected. (kind of alias)
However, for some use cases it might not appropriate. Thanks for your feedback.
Therefore I changed it now and the printer params are now *always* returned.
The flag DN_DEFAULTPRN is now only taken to decide whether or not to change the default printer when PropPrinterDefault = True.
Quote:
Originally Posted by
Simos
Is it possible to use CommonDialog as above and skip User input like when PropFlags = CdlPDReturnDefault
No.
-
Re: CommonControls (Replacement of the MS common controls)
-
Re: CommonControls (Replacement of the MS common controls)
please check also:
with new CommonDialog: .ShowPrinter: end with
In the Dialog click Preferences and then click OK.
You must use Task Manager to end the IDE or restart the pc if this action was from an exe
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Simos
please check also:
with new CommonDialog: .ShowPrinter: end with
In the Dialog click Preferences and then click OK.
You must use Task Manager to end the IDE or restart the pc if this action was from an exe
I don't understand anything..
-
Re: CommonControls (Replacement of the MS common controls)
just call .ShowPrinter . When the PrintDialog appears then click the button Preferences. When the new Dialog appears click the button OK.
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Simos
just call .ShowPrinter . When the PrintDialog appears then click the button Preferences. When the new Dialog appears click the button OK.
Attachment 174969
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Simos
I found that this problem exists only if the first selected printer is "Microsoft Print to PDF"
If you click on any other printer then PrintDialog->Preferences->OK works fine
Next click the printer "Microsoft Print to PDF" then Preferences->OK don't crash !!!
-
Re: CommonControls (Replacement of the MS common controls)
Sorry to bother you.
In order to reproduce the CommonDialog crash you must:
1. set "Miscrosoft Print to PDF" printer as default OR set PrinterName="Microsoft Print to PDF", PrinterPort="Ne01:", PrinterDriver="winspool"
2. call ShowPrinter and when PrintDialog appears with the above printer selected, don't click on any other printer … just click Preferences and then OK
I hope that this time I was able to give you the correct info to reproduce the crash.
-
Re: CommonControls (Replacement of the MS common controls)
Please let me know if you reproduced the problem
-
Re: CommonControls (Replacement of the MS common controls)
About the CommonDialog problem:
MSDN: The DEVMODE structure actually used by a printer driver contains the device-independent part
followed by a driver-specific part that varies in size and content with each driver and driver version.
Because of this driver dependence, it is very important for applications to query the driver for the correct
size of the DEVMODE structure before allocating a buffer for it.
I have changed the ShowPrinter function to copy DEVMODE structure in the correct buffer as above and the crash problem is fixed now.
If you wish I can upload it.
Thank you
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Simos
About the CommonDialog problem:
MSDN: The DEVMODE structure actually used by a printer driver contains the device-independent part
followed by a driver-specific part that varies in size and content with each driver and driver version.
Because of this driver dependence, it is very important for applications to query the driver for the correct
size of the DEVMODE structure before allocating a buffer for it.
I have changed the ShowPrinter function to copy DEVMODE structure in the correct buffer as above and the crash problem is fixed now.
If you wish I can upload it.
Thank you
Please. Thanks
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
-
1 Attachment(s)
Re: CommonControls (Replacement of the MS common controls)
I created the Private Function PrinterDevMode(ByVal hWndOwner As Long, ByRef dmOutBuf() As Byte, ByRef bufsize As Long) As Boolean
and updated ShowPrinter, ShowPrinterEx and ShowPageSetup.
Attachment 175013
-
Re: CommonControls (Replacement of the MS common controls)
New issue: propPrinterPort = Left$(Buffer, InStr(Buffer, vbNullChar) - 1)
It seems that the last vbNullChar is optional.
Error if you select "OneNote" printer.
Fixed as: propPrinterPort = Left$(Buffer, InStr(Buffer & vbNullChar, vbNullChar) - 1)
-
Re: CommonControls (Replacement of the MS common controls)
@Simos, great bug reports. Such things are needed. Will ensure that all gets fixed soon. Thanks
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
@Simos, great bug reports. Such things are needed. Will ensure that all gets fixed soon. Thanks
Krool. I know that CommonDialog is not on this thread contents and you can't deal with it now.
Maybe I should work on this and when finished I will let you know. I will mark all changes.
Is this ok?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Simos
Maybe I should work on this and when finished I will let you know. I will mark all changes.
Is this ok?
Not needed. I already released an update now to address
1. the issue with the vbNullChar
2. the DEVMODE structure
In fact I did go another way than you did for point 2.
You query the whole DEVMODE struct.
However, I do the "light version" and only retrieve the buffer length to define DMDriverExtra.
And then of course in the allocation to add the DMDriverExtra.
Code:
DMODE.DMSize = LenB(DMODE)
If PropPrinterDefaultInit = False And Not (PropPrinterDriver = vbNullString Or PropPrinterName = vbNullString Or PropPrinterPort = vbNullString) Then
DMODE.DMDriverExtra = GetDMDriverExtra(DMODE.DMSize, PropPrinterName)
Buffer = Left$(PropPrinterName, CCHDEVICENAME)
CopyMemory DMODE.DMDeviceName(0), ByVal StrPtr(Buffer), LenB(Buffer)
Else
DMODE.DMDriverExtra = GetDMDriverExtra(DMODE.DMSize)
End If
[...]
PDLG.hDevMode = GlobalAlloc(GMEM_MOVEABLE Or GMEM_ZEROINIT, LenB(DMODE) + DMODE.DMDriverExtra)
The helper function GetDMDriverExtra: (using OpenPrinterW/DocumentPropertiesW)
Code:
Private Declare Function DocumentProperties Lib "winspool.drv" Alias "DocumentPropertiesW" (ByVal hWnd As Long, ByVal hPrinter As Long, ByVal lpszDeviceName As Long, ByVal lpDevModeOutput As Long, ByVal lpDevModeInput As Long, ByVal fMode As Long) As Long
Private Declare Function OpenPrinter Lib "winspool.drv" Alias "OpenPrinterW" (ByVal lpszPrinterName As Long, ByRef hPrinter As Long, ByVal lpDefault As Long) As Long
Private Declare Function ClosePrinter Lib "winspool.drv" (ByVal hPrinter As Long) As Long
Private Declare Function GetDefaultPrinter Lib "winspool.drv" Alias "GetDefaultPrinterW" (ByVal lpszPrinterName As Long, ByRef cch As Long) As Long
Private Function GetDMDriverExtra(ByVal DMSize As Long, Optional ByVal PrinterName As String) As Long
' According to MSDN:
' The DEVMODE structure actually used by a printer driver contains the device-independent part
' followed by a driver-specific part that varies in size and content with each driver and driver version.
' Because of this driver dependence, it is very important for applications to query the driver for the correct
' size of the DEVMODE structure before allocating a buffer for it.
If PrinterName = vbNullString Then
Dim Length As Long
GetDefaultPrinter 0, Length
If Length > 0 Then
Dim Buffer As String
Buffer = String(Length, vbNullChar)
GetDefaultPrinter StrPtr(Buffer), Length
PrinterName = Left$(Buffer, Length - 1)
End If
End If
Dim hPrinter As Long
If OpenPrinter(StrPtr(PrinterName), hPrinter, 0) Then
Dim RetVal As Long
RetVal = DocumentProperties(0, hPrinter, StrPtr(PrinterName), 0, 0, 0)
If RetVal > -1 Then
If RetVal > DMSize Then GetDMDriverExtra = RetVal - DMSize
End If
ClosePrinter hPrinter
hPrinter = 0
End If
End Function
-
Re: CommonControls (Replacement of the MS common controls)
-
Re: CommonControls (Replacement of the MS common controls)
About vbNullChar: You must also add size to CCHDEVNAMESEXTRA. OneDriver printer has wExtra > 120
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Simos
About vbNullChar: You must also add size to CCHDEVNAMESEXTRA. OneDriver printer has wExtra > 120
It's defined currently as 100. What value do you suggest?
There is no clear definition. I guess it can be any?
So let's go for 200 then?
Edit:
Also must the dmSpecVersion be always set fixed to = DM_SPECVERSION ?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
It's defined currently as 100. What value do you suggest?
There is no clear definition. I guess it can be any?
So let's go for 200 then?
Edit:
Also must the dmSpecVersion be always set fixed to = DM_SPECVERSION ?
1.200 should be sufficient enough to cover long Network Printer names and PortNames like OneNote. Just in case don't remove the last "& vbNullChar"
2.I don't know. This is why I fetched the driver's buffer. The info about DeviceName, SpecVersion, … exist in that buffer and you don't have to set these values to DMODE
QUESTION:
Will you add the CommonDialogW to your excellent collection?
If you don't and with your permission I will create an ActiveX CommonDialogW
Maybe you don't know that your CommomDialogW solves the problem of "Generic / Text" printer and "Device font 10cpi"
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Simos
1.200 should be sufficient enough to cover long Network Printer names and PortNames like OneNote. Just in case don't remove the last "& vbNullChar"
2.I don't know. This is why I fetched the driver's buffer. The info about DeviceName, SpecVersion, … exist in that buffer and you don't have to set these values to DMODE
QUESTION:
Will you add the CommonDialogW to your excellent collection?
If you don't and with your permission I will create an ActiveX CommonDialogW
Maybe you don't know that your CommomDialogW solves the problem of "Generic / Text" printer and "Device font 10cpi"
CommonDialog is included in the OCX. Don't get your question.
-
Re: CommonControls (Replacement of the MS common controls)
:)Sorry...Yes it exists in toolbar. Was it there a year ago?
-
Re: CommonControls (Replacement of the MS common controls)
No... Actually it's not in the toolbox "ComCtlsDemo" project
-
Re: CommonControls (Replacement of the MS common controls)
Sorry... Forget the above. I was just looking the controls collection. (Replace vb's CommonDialog). No need to make a UserControl for this.
Just curious... Do you know the "Generic / Text" and "Device font 10cpi" problem ?
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Simos
Do you know the "Generic / Text" and "Device font 10cpi" problem ?
No I don't.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Krool
No I don't.
Easy to reproduce.
Use vbCommonDialog or any other wrapper PrintDlgA (vbAccelerator, …). Select this printer and print something(even to file)
That's it. The printer object's font changes to "Device Font 10cpi" and there is no way to set another font to the printer.
You must exit the app and start over. The strange thing is that if the first printout off the app was with another normal printer this problem no longer exists. I don't know if this exists only in Unicode environments.(here is Greece dif.codepage). Since then I always check the first printout and stop it if the printer is the above.
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Simos
2.I don't know. This is why I fetched the driver's buffer. The info about DeviceName, SpecVersion, … exist in that buffer and you don't have to set these values to DMODE
The "correct" way is even longer.
https://support.microsoft.com/en-us/...rties-function
1. Determine size (fMode = 0)
2. Read (fMode = DM_OUT_BUFFER)
3. Modify DevMode
4. Merge (fMode = DM_IN_BUFFER OR'ing DM_OUT_BUFFER)
You skipped point 4 and I skipped all except 3, with yesterday update skipped 2 and 4.
I will do it properly and will update soon w/o any skips.
-
Re: CommonControls (Replacement of the MS common controls)
I think step 4 is not needed. You have already merged the DevMode part. PrintDlgW will do the rest
-
Re: CommonControls (Replacement of the MS common controls)
I think step 4 was actually when I copied DMODE back to the dmoutbuf() and then CopyMemory ByVal lpDevMode, dmOutbuf(0), buflen
-
Re: CommonControls (Replacement of the MS common controls)
Quote:
Originally Posted by
Simos
I think step 4 was actually when I copied DMODE back to the dmoutbuf() and then CopyMemory ByVal lpDevMode, dmOutbuf(0), buflen
That's the hard merge. However DM_IN_BUFFER OR'ing DM_OUT_BUFFER merges involving the driver so that eventual amendments in the private section can be done, according to MSDN.
-
Re: CommonControls (Replacement of the MS common controls)
I still think that since we return in dmOutbuf() the size of our DMODE struct the driver will adjust the private part. But you may not agree.
-
Re: CommonControls (Replacement of the MS common controls)
when DMODE gets the dmOutbuf() data the DMODE.DMSize is either 0 or 1. This is something to think about. Perhaps Old/New DMODE struct
-
Re: CommonControls (Replacement of the MS common controls)
Please run this:
Sub Main()
Debug.Print Printer.FontName ' should be any font
Dim obj As Printer
For Each obj In Printers
If obj.DeviceName = "Generic / Text Only" Then
Set Printer = obj
Debug.Print Printer.FontName ' also the above font
Printer.FontName = "Tahoma" ' or any other font
Debug.Print Printer.FontName ' Ooops...Device Font 10cpi... you must exit IDE
Exit For
End If
Next
End Sub
-
Re: CommonControls (Replacement of the MS common controls)
Since you are working on CommonDialogW maybe you should make some other changes to make it more user friendly.
1. Trim out not supported flags. e.e. CdlPDNoNetworkButton and cdlPDPrintSetup not supported in ShowPrinterEx and the error returned is generic
2. Maybe propFlags should be set to zero on exit of all Show functions. (After ShowPrinter I called ShowColor without setting any flags and I got an error)