I'm maintaining a VB6 application that makes extensive use of the old VBAccelerator SGrid 2.0 (vbalGrid, using another Grid control isn't really an option). I need to change the grids font at run-time, and nothing I seem to do works to change the header font, only changing the grid controls Font property at design time seems to actually change the font.
Here is the code I've tried, which I would have thought would work:
Dim Fnt As New StdFont
Set Fnt = vbalGrid.Font
Fnt.Name = "MS Sans Serif"
Set vbalGrid.Font = Fnt
This sets the font for the body of the grid just fine, but you do have to clear and repopulate the grid if it already has data. However the header doesn't change, even if you clear all the columns and recreate them.
It looks like there is a bug in the Property Set Font routine -- it does not call BuildMemDC to invalidate its buffered output DC.
Try RowHeight(1) = RowHeight(1) + 1 or similar nudge to force BuildMemDC getting called. You'll have to increase the height of some row above its internal m_lMaxRowHeight variable for the rebuild to kick in.
Related
So I'm writing a script to modify quickly a VB6 application's interface with COM controls. (Created in C# .net). Most of it works fine, but some panels are giving me a lot of trouble.
Basically, I open the .frm file and read it, and when I find some controls I modify their values or insert new things. When I find a panel, I create a different panel around it so it looks better. I'll put, say Top = 2340 in the file for my new element. If I open the .frm in notepad, I can clearly see that the value of Top is at 2340. Once I open VB6, the panel's top value is at Top = 8190. It also modifies the Left value, but nothing else. If I save and exit vb6, then reopen the .frm in notepad, the Top value will be saved at 8190.
Why does VB6 uses different values than the ones in the .frm file? Is it trying to avoid elements stacking on top of each other ? What is happening between reading the file and opening it, that forces a different value of the Top property?
Just a theory, but I believe the issue is that the ScaleMode property isn't setup right. By default, unless the container window has the property, it'll be set to Twips. So what may be valid under certain containers won't be valid in other containers.
The MDIForm container, for example, forces Twips, and may even re-position objects based on alignment.
If this is the form itself, which I don't think it is but worth mentioning, make sure the StartUpPosition is properly set to 0 (Manual).
When I run my report from VS10, I have to switch everytime to print-layout. Because I need to make 100+ small adjustment to my big table, I have to press the print-layout button everytime to see the result.
Is there a way, I can set it up, so I start by seeing the print-layout when running the form?
It´s an old post but found the exact answer. Setting Print-Layout instead of setting Zoom mode for the ReportViewer.
ReportViewer1.SetDisplayMode(DisplayMode.PrintLayout)
It looks like you can adjust report viewer properties. I found a adjustment that sets the zoom, in your case (print layout = whole page) so the default would need to be changed.
Here is the VB script for it from MS.
'Declaration
<CategoryAttribute("Appearance")> _
<DefaultValueAttribute(ZoomMode.Percent)> _
Public Property ZoomMode As ZoomMode
'Usage
Dim instance As ReportViewer
Dim value As ZoomMode
value = instance.ZoomMode
instance.ZoomMode = value
I don't know if you have to use a # like value = 50 or if you can use value = Whole Page, it seems like the latter can be used since it bases the figures dimensions on the logical page to assume the view size.
Goood luck and check http://msdn.microsoft.com/en-us/library/microsoft.reporting.winforms.reportviewer.zoommode.aspx for further guidance and different code options.
I have this Win32 user-drawn tab control that is created as:
CONTROL "Tab1",IDC_TAB_CONT,"SysTabControl32",TCS_BOTTOM |
TCS_OWNERDRAWFIXED | NOT WS_VISIBLE,0,14,185,88
I'd like for this control to have its tabs resize as never to have to see the "sliding arrows":
Now, pretty much everything about this control works as expected, except for that fact that it won't respond to TabCtrl_SetItemSize. Try as I may, the size I get for the tabs when I get to draw them (in the DRAWITEMSTRUCT passed to WM_DRAWITEM) is always the size that fits the longest caption in them and never the size I've set with TabCtrl_SetItemSize.
However, in the TabCtrl_SetItemSize documentation, it says that:
[TabCtrl_SetItemSize] sets the width and height of tabs in a
fixed-width or owner-drawn tab
control.
The only way I've managed to have a decent resizing is by setting a dummy string of the desired length in it by sending the control a TCM_SETITEM message, and writing the desired text in it at draw time. This is rather inconvenient and not a particularly nice hack.
Is there anybody who would know
Why TabCtrl_SetItemSize isn't working as expected? and/or
How to set the tab size properly?
Many thanks,
joce.
Setting TCS_OWNERDRAWFIXED style is not enough, you have also to add TCS_FIXEDWIDTH style.
The minimum size of a tab is at least icon width + 3 if icon is present.
If you have icons (imageList attached to tabControl), you might get those "sliding arrows" even with fixed width (if there is less space available than: number of tabs*(icon width+3)
I'm running into a problem trying to anchor a textbox to a form on all 4 sides. I added a textbox to a form and set the Multiline property to True and the Anchor property to Left, Right, Up, and Down so that the textbox will expand and shrink with the form at run time. I also have a few other controls above and below the textbox.
The anchoring works correctly in Visual Studio 2005 (i.e. I can resize the form and have the controls expand and shrink as expected), but when I run the project, the bottom of the textbox is extended to the bottom of the form, behind the other controls that would normally appear beneath it. This problem occurs when the form loads, before any resizing is attempted. The anchoring of the textbox is correct for the top, left, and right sides; only the bottom is malfunctioning.
Has anybody heard of this and if so, were you able to find a solution?
Thanks!
UPDATE:
Here is some of the designer code as per Greg D's request (I am only including the stuff that had to do with the textbox itself, not the other controls):
Friend WithEvents txtRecommendationText1 As System.Windows.Forms.TextBox
<System.Diagnostics.DebuggerStepThrough()> _
Private Sub InitializeComponent()
Me.txtRecommendationText1 = New System.Windows.Forms.TextBox
' ...snip...
'txtRecommendationText1
Me.txtRecommendationText1.Anchor = CType((((System.Windows.Forms.AnchorStyles.Top Or System.Windows.Forms.AnchorStyles.Bottom) _
Or System.Windows.Forms.AnchorStyles.Left) _
Or System.Windows.Forms.AnchorStyles.Right), System.Windows.Forms.AnchorStyles)
Me.txtRecommendationText1.Location = New System.Drawing.Point(4, 127)
Me.txtRecommendationText1.Multiline = True
Me.txtRecommendationText1.Name = "txtRecommendationText1"
Me.txtRecommendationText1.Size = New System.Drawing.Size(223, 149)
Me.txtRecommendationText1.TabIndex = 10
End Sub
ANOTHER UPDATE:
The textbox I originally posted about was not inherited from a baseclass form (although it was added to a custom User Control class; I probably should have mentioned that earlier), but I recently ran into the same problem on a totally unrelated set of controls that were inherited from a baseclass form. It's easy to blame these problems on possible bugs in the .NET framework, but it's really starting to look that way to me.
Is your Form localized? Check the resource files for an entry with Textbox.Size, delete is and reset the size.
Is your Form inherited and is the Textbox on the baseform? Try setting the Textbox's access modifier to Protected or Public.
Have you implemented custom resize logic? Turn it off and see if the problem is still there.
Have you entered a Textbox.MinimumSize/MaximumSize? Remove or change the value.
It might also be a combination of these things...
Does the form snap back to the expected layout when you resize it after it's been initialized weirdly? Also, have you set a Height or MinimumHeight/MaximumHeight property for the text box?
If possible, a few snippets from the designer code might be useful. :)
One possibility that I've run into in the past is DPI. If you're running/testing your code on a machine with a different DPI setting than the machine that you're developing on, you may observe some strange things.
The anchor functionality essentially establishes a fixed distance between the edge of a control and the edge of the control's parent. Is your textbox embedded within another control (e.g., a panel) that doesn't have its anchors properly set? Right clicking on the text box in the designer should pop up a menu that lets you select any controls that exist underneath it, also.
Does your program include any custom resize logic, or does it modify the size of the textbox programmatically outside of designer-generated code? That might also result in weird behavior. I've assumed maintenance for a number of pieces of software at my organization where the original developers spent a great deal of time implementing (buggy) resize logic that I had to tear out so that I could just let the designer-generated code do the work for me.
The textbox I originally posted about was not inherited from a baseclass form (although it was added to a custom User Control class; I probably should have mentioned that earlier), but I recently ran into the same problem on a totally unrelated set of controls that were inherited from a baseclass form. It's easy to blame these problems on possible bugs in the .NET framework, but it's really starting to look that way to me.
It's very likely because of the 'AutoScaleMode' property being set in InitializeComponent(). Try setting it to 'None' and see if that fixes it. I've had these problem a couple of times now.
In VB6, I have a DTPicker control on a form. (The DTPicker is the calendar date/time selector, included in Microsoft Windows Common Controls-2 6.0, available from the Components dialog.)
While there are many properties to affect the colors of the calendar when it's dropped down, there is no property that allows changing the color of the date that's displayed in the textbox. I'm looking for something like the standard TextBox's ForeColor property.
Does anyone have a little API magic to allow me to simulate that property?
I hate to post something that is not really helpful, but this appears to be something beyond the scope of what Microsoft intended developers to do with the control. While there must certainly be an API call to set the color (Windows certainly knows to paint it black when enabled and gray when disabled), the method to do so escapes me.
My recommendation, should no one else respond with how to do what you need, is to either obtain a new DateTime Picker control with the needed properties (it would seem that there are a few 3rd party options), or "roll your own" control.
FWIW, this same issue exists in VB.NET with the exception being that Microsoft specifically overrides (and then hides) the ForeColor (and BackColor) properties inherited from the generic Control object to do nothing.
I'm going to address two issues with the DatePicker object and a workaround for them.
You cannot put a blank value into DatePicker, which lead me to the 2nd problem.
You cannot change the font color to at least make it appear blank.
To keep the functionality of the DatePicker AND gain the ability to have a blank value and your regular font formatting options (colors, etc), I used two objects. First make a DTP object and set the width so that you can only really see the drop down arrow. For me this was 15. Then make a regular TextBox that is wide enough to hold your date. Put the DTP arrow directly to the right (or left) of the text box. Then you simply add code to the Change event of the DTP to copy its .Value into the .Text of the TextBox like so:
Private Sub MyDTP_Change()
MyUserForm.MyDateTextBox.Text = MyUserForm.MyDTP.Value
End Sub
Then have any data references you need access the MyDateTextBox.Text instead of the MyDTP.Value and presto! You get the functionality of the DTP with the formatting control of a regular TextBox.
EDIT:
Sorry JeffK, I wasn't working with VB in a production environment 9 years ago. :) I would like to add the other side of the functionality to this as well. This allows 2-way syncing between the TextBox and the DTP. IE: Manually enter a date into the TextBox and the DTP Calendar follows. If the TextBox is blank or has an invalid date, the DTP defaults to today's date.
Private Sub MyDateTextBox_Change()
If MyUserForm.MyDateTextBox.Text <> "" And
IsDate(MyUserForm.MyDateTextBox.Text) = True Then
If CDate(MyUserForm.MyDateTextBox.Text) <= MyUserForm.MyDPT.MaxDate And _
CDate(MyUserForm.MyDateTextBox.Text) >= MyUserForm.MyDPT.MinDate Then
MyUserForm.MyDTP.Value = MyUserForm.MyDateTextBox.Text
Else
MyUserForm.MyDTP.Value = Date
End If
Else
MyUserForm.MyDTP.Value = Date
End If
End Sub