I'm not even sure what to call it so let me explain the scenario and hopefully a light bulb goes off for somebody else. I can't do a full code share to reproduce because it just isn't an option, anyhow I digress.
So, here's the basics.
Multiple DataTemplate's set via;
public DataTemplate ABCTemplate
{
get { return (DataTemplate) GetValue(ABCTemplateProperty); }
set { SetValue(ABCTemplateTemplateProperty, value); }
}
Which are swapped out via;
public override DataTemplate SelectTemplate(object item, DependencyObject container)
{
var something = (thestuff)item;
switch (something.Id)
{
case (int)thestuff.Type.ABC: { return ABCTemplate; }
case (int)thestuff.Type.DEF: { return DEFTemplate; }
case (int)thestuff.Type.GHI: { return GHITemplate; }
case (int)thestuff.Type.JKL: { return JKLTemplate; }
}
return base.SelectTemplate(item, container);
}
etc, etc, etc. Each DataTemplate is a DataGrid (no I did not make this and I can't rewrite it).
Here's the weird mystery part that has me stumped that I'll explain best I can.
On initial load of the screen everything is fine, the data loads fine, everything is peachy. HOWEVER upon Save (even without any changes) once the busy indicator disposes then ONLY the Column Headers of the DataGrids will remain visible UNTIL you resize the screen even the slightest bit. Which I assume causes SizeChanged to UpdateLayout()?
My question is, has anyone seen this behavior before? Why the hell would the DataGrid of each template render the Column Headers, but then NOT render the rows until just a SizeChanged event, and most importantly, how can I fix this P.O.S.?
I tried the first stuff I could think of like just hard setting some sizes since I took a shot in the dark on the fact that changing the window size even the slightest bit causes the data to return to view but in reality, I'm stumped and doing that just made it less predictably reproducible.
I'll happily buy beer for anyone that can save my sanity. Thanks.
This actually does ring a bell. I had to fight a similar DataGrid rendering issue. Here is my story:
The content disappeared or was completely white when we added columns, after a while I found out it happened when the combined width of all columns exceeded a certain number. I don't think it was Int32.MaxValue, it was probably a smaller number, maybe it was a power of two, but that is not important or required. (see my explanation further down)
So your save operation's busy indicator might effect the visualState in any way, some kind of focus border or stuff might be rendered and just hits this magical limit, an overflow will happen.
Now imagine some code that for example calculates the width of a contentPanel or Presenter (or anything related to showing your content) sums up all the parts, and an overflow happens, what will be the result? yeah, exactly, the width will be far in the negative. So it actually might be rendered by the engine, either off screen or just outside of the element's actual display area.
You can actually reproduce this and witness it with a TextBox in a try-out project: Have a TextBox and fill it with random characters via Ctrl+A, Ctrl+C, Ctrl+V, and onTextChanged -> Debug.WriteLine(textbox.Text.GetRenderedWidth()).
(GetRenderedWidth is an extension method I wrote, can give you the code if you want. But it is not super accurate.)
As soon as the rendered width reaches ca. 39,235 you can see a change in the rendering of the Ctrl+A text highlighter: The content is gone! But actually it is just rendered into negative direction (you can turn on EnableRedrawRegions to see it rendered in the wrong direction). and everything is back to normal when you remove the last character again.
So my advise is: turn on EnableRedrawRegions, see if you can see a change of the redrawn regions when your rendering issue occurrs. If you can spot a region is drawn just left of you DataGrid, chances are that that is actually your grid content.
[Edit 1]
If it turns out that the visualState change of the grid is somehow causing this bug, your fix might be as simple as onBusyIndicatorDone -> VisualStateManager.GoToState(grid,"normal",false);
[Edit 2]
You can trigger a redraw with InvalidateArrange or InvalidateMeasure: grid.InvalidateArrange() or grid.InvalidateMeasure()
Related
I have the same problem as described here:
DataGridView flickers ONLY when the rows fits roughly one page
Basically, where the number of rows in a DataGridView is roughly the same as the size of the view itself, the DataGridView appears to get caught in an endless loop of resizing the rows/columns.
From running performance profiling on the DataGridView, it appears the onColumnWidthChanged and onRowHeightChanged events are continually firing. My hunch is that the vertical scrollbar is causing the issue in that:
(1) when the scroll bar isn't showing, the DataGridView works out row heights, but that for some reason pushes the final row off the screen
(2) that prompts the scroll bar to show, which prompts a row height/column width recalculation, but for some reason the rows then fit (I'm not quite sure why this would be - if the scroll bar is there, you'd expect there to be less space)
(3) that prompts the scroll bar to be removed .... go back to bullet (1)
This endless loop significantly impairs the UI thread, and is visually unsightly.
I've been trying to find a way of detecting and overriding the behaviour (e.g. by trying to detect when the final row is showing, and then force disabling the vertical scrollbar), without any luck so far.
Has anyone come across this please and/or have any suggestions?
Thanks in advance.
It seems you can break the endless loop by overriding the OnCellValueChanged and OnRowHeightChanged events:
protected override void OnCellValueChanged(DataGridViewCellEventArgs e)
{
if (e.RowIndex != -1)
{
this.Rows[e.RowIndex].MinimumHeight = 2;
}
base.OnCellValueChanged(e);
}
and
protected override void OnRowHeightChanged(DataGridViewRowEventArgs e)
{
e.Row.MinimumHeight = e.Row.Height;
base.OnRowHeightChanged(e);
}
This basically locks the minimum row height to the height when the row height is updated, and then releases it when the cell value is changed.
Therefore, when the internal DataGridView code tries to resize the rows, they get locked to a minimum (meaning they won't be reduced in size again, which is what causes the endless loop). When a user (or code) updates a cell, this constraint is released so that the rows can resize when they need to.
I've been developing with Xamarin and iOS for about two weeks now, and currently I'm attempting to figure out why a strange bug is happening. I've looked all over Google and even SO, but can't find an answer...one that works, anyways. As the title says, whenever I change the Translucent boolean property of my NavigationController.NavigationBar, extra padding is added for seemingly no reason. This can be seen in the image below:
The line of code I use for this is this.NavigationController.NavigationBar.Translucent = false; and without that line, the application looks like this:
Other than that line, the NavigationController.NavigationBar is unedited. So, does anyone know what I'm doing wrong? Any help would be much appreciated...thanks SO!
It depends on the way how you construct your views and their containments.
Make sure that EdgesForExtendedLayout (Apple Docu) has the right value. I would suggest UIRectEdge.All.
In the case you are using a scrollView als check the automaticallyAdjustsScrollViewInsets property.
So, I actually figured out through posting on the Xamarin Forums and browsing through their documentation that the UINavigationBar.Translucent property adjusts the view if you turn it off such that all of the screen's contents are visible beneath the now-opaque UINavigationBar. I was simply placing the UI elements with unnecessarily large Y-values because I was unaware of the screen change after .Translucent = false;
I changed the .Frame = new CGRect(x, y, w, h) properties of each UI element with respect to 0 being right below the navigation bar, not underneath it.
Let me start off by saying I tried to research this, but I'm unable to word it to where I wouldn't get irrelevant results.
So here's the issue. I have a button (actually, 6 buttons) which have a rounded corner appearance. They're saved as PNGs, and loaded into the button using button.BackgroundImage = [resource]. Five of them work perfectly fine. When they're clicked, the background image is changed and, again, looks fine - including changing back when the button is no longer pressed. Then there's the button in the screenshot below.
I have no clue where this green color is coming from - in fact, when I go pixel-by-pixel over the image using GetPixel, and check the ARGB values, they turn out to be purples with A = 0. Also confusing is that the green only shows up at run-time -- as shown in the image. According to PhotoShop and GiMP, the RGB is 46,139,86 .. GetPixel shows them to be various colors in the purple range, but as an example, at 0,0 it shows 164,119,182 A:0.
Here's the list of things I've tried (some pseudocode):
if (pixel.A == 0) { SetPixel(x,y,Color.Transparent); } -- No change
if (pixel.A == 0) { SetPixel(x,y,Form1.TransparencyKey); } -- See
through to desktop instead of form background (as expected).
Use a known good image (see screenshot) -- No change.
Delete control, copy and paste a known good control (see screenshot)
-- No change.
Add another control, hoping I could hide the flawed one and basically
just ignore it. -- All new buttons have this issue.
Move button to different area of form (long story). -- No change.
Set no background in designer, then set the background in Form1.Load. -- No
change.
Restart Visual Studio. -- No change.
Clean solution, rebuild. -- No change.
Restart computer. -- No change.
Anyone have this issue before, or know what's going on? I have a solution that works (use a panel as a button - I just tested it and the transparency is fine on a new panel) .. but I'd prefer to figure this out. Thanks in advance!
Here's the imgur:
WP8 : Whenever a texbox comes into focus, the corresponding view of the page shifts up by a margin. Due to which the heading of the page gets cut. I have found a solution to this problem here , but it doesn't help. Does not work on WP8. Any solutions are appreciated.
You can disable that shift by changing RenderTransform back to zero:
private void TextBox_GotFocus(object sender, System.Windows.RoutedEventArgs e)
{
App.RootFrame.RenderTransform = new TranslateTransform();
}
First you can disable shift using the RenderTransform back to zero as #Ku6opr mentioned. But the real question is would it really do what you want. Noone likes to type if I can not see what I'm typing, this is the reason behind shifting the view upward.
If you really want to prevent shifting redesigning the view for a smaller space will be a much better option. Only disabling the shift somehow wouldn't help much.
I have a WinForms application that allows you to edit documents. Each document is made of chapters and each chapter holds a collection of RTF blocks. The RTF blocks are loaded in a PanelControl using Dock = DockStyle.Top.
The problem is that when the total height of a chapter gets too large (estimating > 32768 pixels) the lower blocks are not properly docked: they appear behind one another. When trying to isolate the problem I noticed that this also happens with simpler controls like a LabelControl.
Things I tried are methods like Refresh(), Invalidate() and PerformLayout: they will not resolve the issue.
What does help is resizing the form. After that all controls are laid out correctly.
Can anyone help on how to solve this without resizing the form?
Attached a simple demo-project that illustrates the problem.
From my comment above (seems really to be the problem here):
WinForms (and the GDI in general) is often behaving unpredictably if one tries to use coordinates outside a 16 bit range. Try to avoid that. In the range of possible problems are things just not getting drawn at all, OverflowExceptions at unexpected code positions etc.
If it's possible to you take decision to change this layout, I suggest you to take another approach on showing/editing the documents chapters with some kind of pagination or collapsing RTF blocks into a menu and showing only current.
You see.. it makes a sense the height value be a integer 16-bit value.
A screen is way more tiny than this.
As panel height increases to such a high size. You see that using scroll bar will become very very sensible.. and it's not a good thing.
Content with size 2x, 3x, 5x being scrolled is usable to user. But scrolling a content with height (~32768) of at least (using good resolution monitor w/ window maximized) in optimal case 32x the size of window is very uncomfortable.
Plus, I believe that the productivity of user will decrease due to brain difficulty in locate "things" in a increasing collection of "things".