Microsoft Access seems to limit the form width. This limit is ->very-< small...
Is there any way to bypass this limit?
I try to create a dynamic datasheet view which allows background coloring of rows, onClick events in specific fields, Locking of specific fields, logging of changes etc. I'm using a continous form, that dynamically defines field width, events, sorting, color and position to create this perfekt table, which works really well.
The only limitation for this I've found is the max form width, wich seems to be a simple integer, 32.767 . The size of this seems to be ->much<- smaller than a pixel (I've heard it's 567 per cm.), and so it limits at about 1.2 screen witdh of a HD screen. Thats WAY to small...
I'm not sure what you mean by 32.767 being smaller than a pixel? The max width for a form is 22 inches which is 31680 twips. That is ~1.2x the with of my monitor; you're right. But that seems pretty darn wide. Certainly not very small.
If you need wider than that you can use datasheet view for data entry, or multiple rows of controls in your continuous form, or multiple screens (i.e. tab ontrol, let the users click 'Next' to fill out more data).
This is a logical width to keep you from shooting your self in the foot. People don't like to scroll to the side a lot.
Related
I have a use case where I have a sidepanel containing Searchbox, Some MessageBoxes and two lists which get filtered when user searches for something.
The searchbox and messagebox occupies the fixed height but I want both the lists to occupy equal height and grow if the browser resizes.
Also would be nice to shrink the list if there are less items in one of the lists to give more room to the other one.
Here's what the UI looks like...
I'm currently trying to calculate the height and assigning the height to both the lists manually on browser resize event but I was wondering if there's a better way to do that.
Thanks in advance :)
Use a Stack component, specifying the grow attribute on the Stack.Items that wrap your lists.
https://github.com/microsoft/fluentui/blob/master/packages/office-ui-fabric-react/src/components/Stack/examples/Stack.Vertical.Grow.Example.tsx
I want to create a custom UIView that would be equivalent to a horizontal UIPickerView. The data elements, such as "Mountain View, Sunnyvale, Cupertino, Santa Clara, San Jose" would move left to right. The view would be long and thin. 50px in height, 350x in width sort of thing.
I will need to use protocols to obtain my datasource elements likely, but what I'm more interested in figuring out is the visual aspect of this.
How would I animate things left and right? Should I just make one incredibly long view (off screen), and change the frame left and right. This seems like a bad idea, as likely only 3-5 options need to be visible in the control at one time. If the datasource is 100 elements, there is no point in loading the other 95 off screen in a long view.
So perhaps I should load ~9 or something. The 3-5 on screen, plus an additional ~3 left and right. Each time the control is triggered to move left and right, it will load up another element on the view(?).
Is this a good way to achieve this? A long thin view with ~9 UILabel's. As the control moves to the right, I would shift the further left UILabel to move hidden to the far right, and change the UILabel to be the next in the data source.
I also likely want to change the text size based on its position. If it's currently selected, I either want to bold it and possibly increase the font size. How can I gradually achieve this as the view is moved? It would be weird if the text only changed once it was moved perfectly center inside the view. It should likely gradually grow as it gets closer to the middle.
How can I achieve this?
A collection view would do the trick, obviously there's some coding involved.
I'd suggest you to take a look at the code of, or use, the following library.
I've used it once,does almost exactly what you need and works very well:
AKPickerView
I am working on OS-X app, and I need advice on the window size.
Before someone to jump and declare this question as duplicate, I have read this post:Window Size for Mac application but it didn't help me to solve my issue.
My issue is the following. I use NSTableViews to display some of the data. However in some windows, I am getting horizontal scroll bar in the NSTableView due the numbers of the columns.
Things to be worse, the data in some of the columns are not completly visible, you have to resize the column to reveal the complete text in that cell / column.
I am thinking of increasing the initial window size, but I can't decide how much.
My current window size is 1024 x 768. User can make the app full screen, and window can be resized to be larger than this size, but not smaller.
Any help will be deeply appreciated.
Regards, John
For the table, you should set minimum widths for each column. Select each column in the document outline and view the Size inspector. You should also review the Resizing pop-up on the Attributes inspector.
Similarly, you should review the Column Sizing pop-up on the Attributes inspector for the table view itself.
With respect to the window size, I recommend that you use auto layout if you're not already. Apply appropriate constraints to all of the view, ultimately relating them (directly or indirectly) to the window's content view. Then, don't set a minimum size for the window itself. Let the constraints impose an effective minimum (and potentially even maximum) size.
The trick though, is that not all views will have an intrinsic minimum size. For example, the table view itself may not get any narrower than the sum of the minimum widths of its columns, but it's in a scroll view. The scroll view is allowed to get narrower than the table view, resulting in horizontal scrolling. So, you may need to add an explicit minimum width constraint to the scroll view.
If you set constraits for text inside the rows, you may get some horizontal scrolls. But if you set the constraits for the app elements like UITableView to the borders of the app window, you may resolve this issue.
I was searching google for a way to size the form and the controls with it and came across something that mentioned Control.scale. How do I use the control.scale method to size everything down to the way I want it.
Also, is there a way I can zoom the form out in the designer. I want to create a 1280X800 form, but my screen is 1024X768. I want to be able to zoom out to see the entire form wile still having it's size be 1280X800.
You can use tablelayout panel in order to fit your form in all resolutions.similary a property called anchor, which is also need to be assigned for the controls inside tablelayout panel according to your requirement [top,bottom,left,right] to achieve the same.
By the way you have to use percentage for setting the column's width and row's height in that.
Simply, this way of designing is called as fluid designing.
Table layout panel
I have a RDLC report and I am displaying it on the Report Viewer Control in my front end application. I am able to view the report perfectly.
But the problem arises when I try to export the report to a PDF (using the built-in option).
I print the report in 3 pages whereas my client wants it to be in a single page. I can't figure out the reason for it as in my report viewer I see only one page but in a PDF there are 3 pages.
Can something be done about it so that I can control the size of the report?
The answer is pretty similar to what Dugan said, but it's not always just the margins.
It is pretty simple though:
When you are editing the rdlc file in design mode, firstly click on an empty part of the BODY area of your design. Hit F4 to see the properties tab. Here, you will see a "Size" property. This can be expanded for the width and height. The width you see here represents the width that the body of your report requires as printable area. Even if you have white space all over, the page knows that it needs to keep it as a printable area. It reserves the space, in some sense. As for the height, the system generally knows that it can grow or shrink as necessary, unless you have specified otherwise within your controls therein. So the width is what will, usually, play the most important role.
Next, click on an empty area of the report (outside the header, body, and footer; basically the gray area around the design), then hit F4 to view the properties panel. Under the "Layout" category of the properties, you will see 3 different options:
InteractiveSize,
Margins,
PageSize.
Each of those Size attributes can be expanded to show the Width and Height. The Margins attribute can be expanded for the left/right/top/bottom.
Basically, the pdf export works out of the PageSize (though I generally try to keep Interactive and Page size equal). When the pdf file is rendered via the ReportViewer's built-in export function, the width and height of each "page" within the pdf will be determined by the width and height in the report's PageSize attribute (you could override this if you used your own custom code for the pdf rendering).
As for the margins, they specify how much space MUST be left blank and unprintable between the printable area reserved for your report and the edge of the page.
In other words:
Your report's Body's Width, Plus the Report's Left Margin, Plus the Report's Right Margin, MUST be smaller than or equal to the Report's PageSize's Width!
So...if your margins are too wide, or if your report's body is too wide, or if the PageSize's width is too narrow, the rendered result is forced to be broken down to multiple pages in order to fit!
For example: If my report's body has width 7.75", my Left margin is 0.5", my right margin is 0.5", and the width specified in the PageSize is 8.5", my report will always use 2 pages for each 1 page of data. The 7.75" width of the body, plus 0.5"+0.5" for the margins add up to 8.75", which is larger than the 8.5" available in my page. So the first 7.5" (or so) of each page of my report's body will be shown in the first page, and the rest will be split down to the next page. This will not be done inside the report viewer, as it allows for the report to grow beyond the page size by just adding a scrollbar, but it will be annoyingly noticeable in the pdf export.
In order to make my example report fit in 1 page, I can either try and reduce the body of my report to 7.5" or less, or I can reduce the left and right margins by a total of 0.25" or more (for example, set them to 0.3" for a total reduction of 0.4"), or I can increase the PageSize to something larger than 8.75".
Note: Acrobat Reader is pretty smart and knows about various paper sizes. Therefore, while arbitrary PageSizes will work, it is typically best to use real page sizes. As such, in my last example I would rather set the PageSize to have Width = 11" and Height = 8.5", which is a real letter-size in landscape! Adobe will typically understand this and print properly.
Also Note: Some printers, especially older ones, have trouble printing with less than 0.3" margins. If you want to be nice to your users, you should best keep the margins large enough for those older printers ;)
I hope this helps.
Always maintain body width : 7.5 or less
Left, Right Margin width less than 0.5
Set the Margin width first -> goto main menu Reports->Report Properties->Layout->change left margin and right margin
Total page width :8.5
Ramana
In addtion to watching your widths, I found other unrelated things that can cause extra blank page in the PDF.
If the tablix has any field with word wrap, this can cause it. You might want to make the font smaller if you have long data. Make the font size property equal to something like this:
=iif(len(Fields!RepGroupName.Value) > 25, "6pt","8pt")
Another thing you may have to do. And this helped me when I had no apparent reason for the extra page. In the Report property page, set:
ConsumeContainerWhitespace = true
Yet another thing to watch for. The body size can grow without you knowing it while making changes to the layout. You might have to knock it back down again.
This issue is highly annoying for the end user if not resolved and annoying as heck for us to resolve.
In case anyone else runs into this issue and ends up here, it's most likely a issue with your margins. If the margins are set incorrectly, you will often get "extra" pages that appear when you try and print, whereas when you view the document everything is fine.