I have an Access 365 application with a main form and multiple modal pop-up dialogs. I'm reading the .WindowLeft and .WindowTop properties of the main form in conjunction with the .Move method in the Form_Load code in the pop-up to place the dialogs where I want them (at a fixed offset, to the right and down, so the pop-ups are always over the main form).
This works fine on the main screen of a dual monitor system where the screens are used as an Extended Display. When I drag the main form to the right onto the second monitor, it continues to work as expected until I get too far to the right. It appears that the maximum twip value for WindowLeft = 32760 (on my 1920x1080 monitors, anyway). If WindowLeft on the main form + the fixed offset for my dialogs exceeds this value, I get overflow errors when the dialog tries to open. If I keep dragging the main form to the right, WindowLeft starts returning negative values, and those start moving back toward zero as I continue to drag the form further to the right. It's like the "anchor point" for WindowLeft shifts.
Since my goal is to open my modal dialogs at a predictable position regardless of the main form's position, once I understood this behavior, I thought I could code around it by adjusting my offset if the main form WindowLeft is < 0. That works in theory, but it means the code wants to .Move the dialog to a negative value (say, -20000 twips or so). This doesn't cause an error, but the dialog just won't display when I do that. If I Alt-Tab, Windows thinks it is open, but it isn't visible. I've tried .Repaint, .SetFocus, and .Visible = True to try to give it a kick in the pants so it will display, but without success.
Has anyone run into this before? If so, how did you handle it?
Related
I have seen some mind-binding situations with SSRS reports in my few years of using it, and I've been able to design around most issues and get it to do everything I've been asked to do.
But apparently, not something extremely simple!
I'm using Visual Studio 2019 version 16.7.2 with the Microsoft SQL Server Reporting Services Designers
version 15.0.19124.0 installed. There's no data bound to the report, this is just a simple design concept.
I have a report that has a static custom page size (in centimetres), interactive size and no margins (12.8 x 17.8cm).
The body size is deliberately set to make it a two page report (2 x the page height).
'ConsumeContainerWhiteSpace' on the report properties is set to true.
Page 1 has an image, consuming the entire space of Page 1 (size of 12.8 x 17.8), with a Text box placed near the bottom right of the image (overlaying it, but not exceeding the width or height of the page, and is set to not grow).
Page 2 is exactly the same, with the content starting where Page 2 would and should start (0, 17.8). However, the Page 2 content is set to hidden (hidden = true, on both the image and the textbox).
When previewed, the report renders two pages, one of which is blank.
If I take the Page 2 content textbox off, and preview it, the report renders as one page (as I need it to).
The same issue occurs if I replace the textbox with a Rectangle or Tablix (the two objects I really need to use in this report as well as the textbox located where it is) and set them to hidden.
Moving any of these objects to the top of Page 2, still results in the same behaviour.
It seems that certain objects, despite being hidden, have space allocated that can't be 'rolled up / truncated / shrunk'. Is this 'by design behaviour'?
Is there some form of magic-witch-craftery I'm missing here to get this to work, or simply something I'm not understanding... ?
Thanks for reading!
Note: So far I have tried the 'Switch to inches, then back to centimeters' solution mentioned in other posts along these lines, have varied 'Keep together' properties, checked 'CanGrow' and 'CanShrink' property changes - all of which have not helped find a solution.
The report body should be set at most wide enough to fit on your output page and long enough to hold all your report items. When you want different items to appear on a new page, put them in a container with a page break set either before or after (whichever is most appropriate). This can also be handled in a data driven manner using page breaks on table groups.
There is no requirement to have white space within your report design to 'fill up' the rest of the page on the rendered report.
If you want anything to appear at the bottom of the report, simply put it in the footer section. If you want specific things to appear at the bottom of the page of different heights on different pages, that is more of a challenge and will usually require some clever data driven spacers within the report body.
For some reason my continuous form is nearly as long as my screen, even when I only have a few records. In design view, I can see that the detail section is supposedly only .333" so I'm not sure what is causing this. I'd prefer that the form size be dynamic, but would also settle for a static height at this point. Just want something less obnoxiously large. Anyone know a reason this might be happening and how to fix it?
Open the form in design view. Set the forms border style to “sizable”. You don’t have to, but I would also in the format tab set auto size = no, fit to screen = no.
Now flip the form into regular view. At this point, re-size the form to as you want. Now hit ctrl-s, and close the form.
You can now re-launch the form, and you see the size you set sticks. However, because the border style is “sizable”, then users can re-size the form. If you don’t want this to occur, then open form in design view (after close and doing above steps). Now change the border style to “thin” and close the form. (Answer yes to save).
At this point, when you launch the form, your sized settings will stick, and you (and users) cannot re-size the form.
If you need to change the size, then simply follow the above steps again. Thus open in design view, set border type to sizeable, flip into regular form view. Size the form as desired, and then hit ctrl-s to “save/freeze” the size. As noted, change the border style back to thin if you wish to prevent users etc. from being able to re-size the form.
Open the form in design view, adjust the window hight as desired and click "save" to save the changes. When just closing the form, Access doesn't see that something has changed.
Added:
To illutrate what I mean (after changing the database to use "Overlapping Windows"), here are some screenshots.
Tall window:
Adjust the hight as desired:
Switch to design view of the shortened form (for example by right-clicking the header):
Now, save the form, close it an re-open:
The AutoResize property ensures that no "half detail rows" will be dieplayed when opering the form.
Pretty new to windows phone development...
I'm trying to create an input view that contains a number pad for inputting a sales amount. I know that if you were inputting a number into a text box, you can set the input scope to numeric and then when you click in the text box, a number pad will come up but that's not what I'm trying to do.
I quite literally want the lower half of this screen to be just a number pad that is always up. There is no text box. Rather, as the user is punching in numbers, it'll be displayed in a textblock (a lot like you'd see in a calculator app). I'm not seeing a control for this and google just keeps bringing me back posts about InputScope. I was even thinking of maybe a hack-around where there's an invisible textbox that always has focus, causing the numberpad to always be up, but I don't even know how to cause that behavior either.
Is there a control or technique for this or am I going to have to roll a new user control? Can anyone point me in the right direction?
I would recommend creating your own custom control. That would be the best solution for your condition. There is no inbuilt solution for this situation. I was stuck in the same condition and created a new control with a custom keyboard and a textblock.
And for the hack you mentioned. You can register the LostFocus event of the textbox control and focus the control again using Focus() method of Textbox everytime is loses focus.
I have a GridView in my main app page and I want to do some background processing for the items that are currently in view for the user (high priority), and then of course do the other items too (low priority).
I can access the ScrollBar and the ScrollViewer, but none of them appear to tell me which of my items are in the current scroll window. I could try to hack this in, but it gets tricky because the number of row/columns change based on the size of the scroll region.
http://msdn.microsoft.com/en-us/library/windows/apps/br209745.aspx
http://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.xaml.controls.scrollviewer.aspx
Any help much appreciated!
thanks
There are two general ways you can do this. The first is to get the GridViewItem's AutomationPeer, which actually has a direct method to call. Class information here. I've had problems getting this to actually be usable though. Luckily, there's a second answer. It will require some math to be done, but it's doable.
Get the item container, in this case a GridViewItem, using the GridView's ItemContainerGenerator.
Get the GridView's ScrollViewer. You can search for FindVisualChild<T> methods, there are plenty around.
Do MyGridViewItem.TransformToVisual(MyGridViewScrollViewer).TransformPoint(new Point(0, 0)); This will get you the top left corner of the item, relative to the entire scrollable panel (known as its Extent) of the ScrollViewer (this will be important later).
This will return to you a Point object.
Next, we'll need to find out the range of X values that are currently being displayed in the ScrollViewer.
Note: If you're using a Vertical scrolling ScrollViewer, use the Heights. Horizontal, use the Widths. Both, use both. I am going to do my example using the Horizontal/Width.
Take the HorizontalOffset. This is your current 'lower bound' for the current viewable region.
Take the HorizontalOffset plus the ViewportWidth. This is the upper bound of the current viewable region.
If your Point.X is greater than your lower bound and less than your upper bound, then the item is visible.
If you further need to find out if the whole item is visible, do
this same calculation for Point.X + GridViewItem.Width.
Hope this helps, and happy coding!
You can use VisualTreeHelper to scan the visual tree as Nate suggests, but this is usually not recommended at runtime, especially for tight loops (e.g. checking lots of GridViewItem objects) or complex visual trees. You could do a minor improvement and only calculate the position of these items once and then do a simplified check based on the ScrollViewer.ViewChanged event and offset values, but that still seems a bit too complicated.
If your GridView uses an ItemsPanel that supports virtualization (e.g. the default WrapGrid) - most of the items that are actually loaded into GridView items are actually visible or not far off the screen, so if you bind your GridView to a collection of view models using ItemsSource - you can figure out when these items are accessed by binding to their properties or handling Loaded/Unloaded events on the ItemTemplate and call back to the view models to know when they are getting accessed. That way you can start loading these items when they first start showing up on screen and leave the logic to determine whether they should be loaded to the list control virtualization implementation in the platform.
I have an app with about 40 screens that can all be called in various orders.
I have DoCmd.Maximize on the OnActivate function of every form but when you close a form that is in the foreground the form behind it is back to it's "designed" size. When you then click on the form it activates it and makes it run the DoCmd.Maximize code.
How do I get the whole app to just run full screen?
In Access 2010, you can use File->Options->Document Windows Options->Tabbed Documents, you can set the size of the form to the maximum allowed and remove auto sizing, or you can add code to the close button to maximize the next form.
Forms(Forms.Count - 2).SetFocus
DoCmd.Maximize
Forms.Count -1 is the current form and -2 is the form behind.