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.
Related
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.
For the last few days i have been trying to figure out the best way to get AutomationElement for a specific control in a vb6 application.
My initial way of doing so was by doing a search with the following condition:
new PropertyCondition(AutomationElement.NameProperty, controlName)
I was under the assumption that this was working correctly for about a week in a little test VB6 application.
but i few days ago i realized something... when i dragged a vb6 textbox into the form, the 'Name' property and 'Text' property were both set to 'Text1'
So when i searched with:
new PropertyCondition(AutomationElement.NameProperty, 'Text1')
it return the correct element, but if i then went and set the 'Text' property to '' the same search would bring nothing back.
Question: Has anyone found a way to get a AutomationElement based on a the VB6 control name
What i have tried:
getting the MSAA equivalent interface and looking at the 'Name' property - Result: ''
http://msdn.microsoft.com/en-us/library/windows/desktop/dd318490%28v=vs.85%29.aspx
getting the control based on other properties (AutomationId, RuntimeId) - Result: AutomationId - not all controls seem to have this property available - RuntimeId - changes each time the app runs
I have looked at alot of different sites the main one is listed below - while some say they have manage to get it working - i don't believe i can see how they do it.. or i just dont understand it :$
http://blogs.msdn.com/b/brianmcm/archive/2006/01/17/getting-the-winforms-id-of-a-control.aspx
While i have access to the demo app, i will not access to the production app as that has been created by a third party.
What i plan on doing from here is to get the Automation element based on their position on the form..
Thank you
Can't comment due to low rep. Do you absolutely HAVE to have an AutomationElement?
You may want to look at invoking [user32.dll] (http://pinvoke.net/default.aspx/user32.EnumChildWindows). Look at FindWindowEx, GetWindow, EnumWindows, EnumChildWindows, GetWindowText, etc.
You need the handle of the parent window, so you can use this loop to get it. From there you can use the other functions to get the information you need about the control.
IntPtr hWnd = IntPtr.Zero;
foreach(var process in System.Diagnostics.Process.GetProcesses())
if(condition)
hWnd = process.Handle;
Comment with the exact information you need out of the VB6 window, and I'll give you better code.
You can use the relational position of the AutomationElement in a specific Window (or any other container for that matter), in order to detect it. For example, if you have 5 TextBox AutomationElements in your main window, and you're certain that the order will not be changing, you could create a PropertyCondition on the TextBox class name, and then use the FindAll method to return a collection of AutomationElements and iterate through it, querying the BoundingRectangle property to find out which is the lowest one (or middle, or any other position, for that matter).
I would create a helper method that would return a Dictionary<int,AutomationElement> with the key being the visual position of the AutomationElement, and the value being the AutomationElement itself.
This way you can avoid using a specific Point on your screen (any window size change or element positioning will easily break your code) while not being bound to the AutomationId property.
I have recently been asked if I could make a macro in Excel VBA that will allow a user to type in two numbers and have it automatically drop to the next row. The purpose of this is so they can type in grades for a test two numbers at a time without pressing enter since they aren't great at typing.
When I first heard this he mentioned it was Visual Basic, so I figured I'd just use a TextChanging or TextChanged event in the cell range and have it work off that. However, I haven't been able to find any such event or anything resembling it in the documentation thus far. The first thing that I came across was Workbook_Change, but that only changes after you press enter which is useless to me. Someone else mentioned there is such an event, but couldn't name it directly and I haven't been able to find what they were talking about.
If anyone has any information on if such an event exists or is possible I'd love to know.
The Excel version is 2007 as far as I'm aware.
This, in my opinion, requires a non-programming solution. I absolutely sympathize - it is tough to watch people get old - but you have to draw the line somewhere - for their sake and yours. The enter key is the most basic part of a computer. You could probably write a macro that would automatically hit enter on every even(or odd depending) keystroke in excel - but you're going to run into other problems like not being able to use delete normally. And what if you do want to put a string of text in a cell(like the student's name)? Perhaps it is time to find a non-programming solution. By that I mean someone should have a candid conversation with him about how he wants to solve the problem. Personally, I would offer to type the numbers in for him, as I am accustomed to the number pad - but it is probably better to be more direct and start to discuss retirement.
See this discussion about the limitations of cell edit mode in excel:
http://www.mrexcel.com/forum/excel-questions/524860-call-macro-every-keystroke.html
If you're really heart-set on a programming solution, I would recommend some kind of keystroke logging add-in.
Good Luck.
You could use the Worksheet_SelectionChange event. It is triggered without enter, but it would be triggered a lot.
You could however also create a special user-form for typing in the data, but this might be more work than necessary.
The main problem with using my suggested event is, you will need it as trigger and trigger it yourself, when selecting the next row, so disable event handling before changing the selection.
Edit:
This is a quick solution (paste this into the vba-code of the desired worksheet):
Private Const clngColumnRightToLastGrade = 5
Private Sub Worksheet_SelectionChange(ByVal Target As Range)
If Target.Column = clngColumnRightToLastGrade Then
Application.EnableEvents = False
'offset selection, one row down, two cols to left
Target.Offset(1, -2).Select
Application.EnableEvents = True
End If
End Sub
This will set you one row down and to column C, everytime your selection changes to column E (=5).
You don't have to use a constant of course, you could specify the column to sense in the workbook, so your user might modify it easier by himself.
To make this as an optional feature, you could extend it to autogenerated code. What I have in mind is like a Ribbon-Button, which opens a setupForm to configure, and a Ribbon-Button to activate the configuration, which would place this code in the configured sheet. But this might be a bit over the top.
In Excel 2003, (may be different in Excel2007 ?!) the WorkSheet_Change event is triggered every time the value of a cell is changed wether it is by pressing enter, delete, selecting an other cell after modifying a cell or even when a vba script changes the value of a cell.
I would do something like that:
Private Sub Worksheet_Change(ByVal Target As Range)
Dim RefRange As Range
Set RefRange = Intersect(ActiveSheet.Columns("??????????"), ActiveSheet.UsedRange)
If Not Intersect(Target, RefRange) Is Nothing Then
Target.Offset(0, 1).EntireColumn.Range("A1").Select
'Target.Offset(0, 1).EntireColumn.Range("A65536").End(xlUp).Offset(1,0).Select
End If
End Sub
Seems Janus doesn't think a developer might have a need to highlight the value of a single cell for the user...
It appears the SelStart & SelLength properties apply to the entire grid(wtf?)
I need to show a grid, and when the user enters the desired cell, to highlight the value for them for editing.. You know, highlight the value, start typing replaces the current value...
Should be like a simple txtBox.SelStart=0 & txtBox.SelLength=len(txtBox), But NO!!! Janus is WAY to smart for that...
Anyone out there smarter than Janus? Help!!
Thanks...
This works for me
GridEX1.SetFocus
GridEX1.Row = 2
GridEX1.Col = 3
GridEX1.EditMode = jgexEditModeOn
GridEX1.SelStart = 0
GridEX1.SelLength = 1000
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.