I have the following code:
int a = 0;
protected override void OnPaint(System.Windows.Forms.PaintEventArgs e)
{
base.OnPaint(e);
this.Rows[1].Cells[1].Value = a += 1;
}
and I can see that the variable increases to infinity. I'm using it to paint a graphic making an instance of it and it works fine.
Is this normal? I am creating infinite graph instance? Or I have a problem and I don't know
When you change the value, the grid needs to re-Paint itself., thus firing the Paint event again and re-executing your code.
This behavior is by design.
In general, you should never change external state in a Paint handler; drawing code should be idempotent (other than the provided Graphics).
Paint events are unpredicable and will fire very often.
Related
I'm encountering some bizarre behaviour in a Xamarin Forms iOS Editor.
I have needed the editor to expand horizontally with the width of the text, rather than wrapping.
To achive this, I placed the Editor inside a ScrollView:
<local:ScrollViewEx x:Name="svContent" HorizontalScrollBarVisibility="Default" Orientation="Both"
BackgroundColor="Transparent">
<local:EditorEx x:Name="edContent"
VerticalOptions="Fill" HorizontalOptions="Fill"
WrapLongLines="False"
BackgroundColor="Transparent" />
</local:ScrollViewEx>
In the editor renderer, everytime the text changes, I resize the editor's height and width by getting new dimensions from the following method:
Size GetSizeThatFits()
{
CGSize newSize = Control.SizeThatFits(new CGSize(nfloat.MaxValue, nfloat.MaxValue));
return new Size(newSize.Width, newSize.Height);
}
This all works fine.
But when the editor takes focus and the soft keyboard appears, the system will always horizontally scroll to the maximum x value of the line where the cursor sits. This can cause the cursor to be moved offscreen, and will obviously create confusion for users.
I have tried to control the scrolling by holding the x value in place and only allowing an autoscroll of Y as follows:
private void Editor_Focused(object sender, FocusEventArgs e)
{
double x = sv.ScrollX;
Device.BeginInvokeOnMainThread(() =>
{
sv.ScrollToAsync(x, sv.ScrollY, false);
});
}
This succeeds in holding my x value in place, but now Y for some reason is being automatically set to zero, ignoring the value of sv.ScrollY.
Any ideas?
UPDATE 01
I've just tested the app on an iPhone12 device and the problem is even worse.
With every keystroke the scroll will jump to a different part of the screen.
Is there anyway to completely decouple the keyboard and my Editor/ScrollView scrolling? It would be easier for me to write my scrolling behaviour completely by myself than to keep fighting with the built in behaviour which is not making sense.
UPDATE 02
I may be getting a little closer to my goal.
By subclassing my UITextView and enclosing UIScrollView and overriding their scroll related methods I've manage to kill off most of their unpredictable scroll behaviour:
public override void ScrollRectToVisible(CGRect rect, bool animated)
{
//do nothing
}
public override void SetContentOffset(CGPoint contentOffset, bool animated)
{
//do nothing
}
However some remains. The following scenario is causing problems:
TextChanged event
Reconstruct a UIStringAttributes based on new text, and assign it to Control.AttributedText (Scroll has stayed stable up to this point)
Control.TextStorage.BeginEditing();
Control.AttributedText = astr;
Control.TextStorage.EndEditing();
The next click on the editor to trigger cursor position / SelectionChange however causes an editor scroll setting ScrollY, and sometimes ScrollX to zero.
Why????
Step 3 is hard for me to manage because SelectionChange occurs with both a click on the editor and the entry of text. It also occurs before a TextChange so is hard to predict the cause of SelectionChange.
In addition, even if I bypass Step 2 and don't manually reset my AttributedText, the jump at Step 3 still occurs.
Any ideas?
What is the correct procedure for Scaling a TFrame in C++Builder?
I am developing in PixelsPerInch=120 (aka. Windows font size 125%), but want my forms to work in PixelsPerInch=96 also (aka. default).
My main form loads fine: the VCL code to create a TForm includes a check of whether the design PPI differs from runtime PPI and it scales everything correctly at that point.
However when loading a TFrame, no automatic scaling occurs. So far as I have been able to discover, I have to manually call Frame1->ScaleBy(M, D);.
This mostly works however it has a bug (which I will describe below) so the result is a frame that is not scaled correctly.
What is the proper way to create a Frame and have it scale on load, like a Form does?
I am currently using the following:
// class member
TFrame *f;
// called just before Application->Run()
f = new TFrame(fMain);
int M = fMain->PixelsPerInch;
int D = 120; // Matt's development
if ( M != D )
{
f->ScaleBy(M, D);
}
and then when I want to activate the frame, `f->Parent = fMain->Panel1;
(*f)->ScaleBy(M, D);
I have also tried writing f->Parent = fMain->Panel1; before calling ScaleBy, based on the theory that the Frame has controls using ParentFont and so on, so it might be better if this info is available during scaling; however this introduces other bugs.
The bug is that when calling ScaleBy on a Frame or a Form which has a TLabel which has AutoSize=true and ParentFont=false and Anchors including akBottom, then the Label is displayed much higher up on the window than it should be (maybe even off the top of the window).
I have tracked down the problem: the TControl.ChangeScale function includes a call to ScaleMargins, and the Margin property has an on-set trigger that ends up calling AlignControls for the parent form, which will move any controls with AutoSize=true.
By stepping through Vcl.Controls.pas, I see that my Label scales correctly at first , however when the next control (a radio group, it happens to be) is processed, the AlignControls is triggered, which changes my Label's Top.
The AlignControls function apparently can't handle the TLabel with the parameters I just described when called part-way through a rescaling operation.
I haven't firmly nailed down why, but I think it is because the parent Form or Frame has not yet been scaled (the ScaleControls function scales all the children before scaling the self), so it uses the form's old Height to calculate the actual Top that results from doing alignment to the bottom.
This effect is not triggered when loading the Form the first time, because the scaling code checks for csLoading component state and disables a whole lot of reactionary effects, including the call to AlignControls.
I haven't figured out why the bug is only triggered when ParentFont=false.
My current workaround is to include a line in the FormResize handler that manually realigns the Labels in question with another label that has ParentFont=true (and thus doesn't suffer from the bug).
I have several TextField's inside a window along with a Button, e.g. aButton.
The TextField's, Button, and window all have setImmediate(True).
When a TextField loses focus some validation code is executed and if it fails it calls:
aButton.setEnabled(False);
When incorrect data is entered into one TextField and then focus is lost the debugger shows that aButton.setEnabled(False) is called but aButton still looks enabled.
Two possible things can happen from here:
1.) If one modifies data in another TextField and exits that field (loses focus), the validation can be successful or not for that field but the system knows to call aButton.setEnabled(False) as the previous TextField is still invalid. This time though aButton is visually disabled.
2.) If one clicks on aButton which is visually enabled it produces this warning then visually becomes disabled:
Warning: Ignoring variable change for disabled component < class 'ui.button.Button'>, caption=OK
Currently using Vaadin 6.7.3
Are there any known work arounds to force aButton to visually become disabled immediately (force the client to update) after manually setting it to be disabled?
Sadly I have only Vaadin 7 at my disposal right now, but I checked this anyway. It works as you wanted it to work and I have to jump to the conclusion that this should be the same in Vaadin 6.7.3. This part is not really different in Vaadin7... Have you tried this feature in an isolated code (only a textbox and the button)?
VerticalLayout vlTestContent = new VerticalLayout();
final Button butChangeMe = new Button("Enabled");
final TextField tf = new TextField("Blur", "default value");
tf.addBlurListener(new BlurListener() {
private static final long serialVersionUID = 5544993392287938660L;
#Override
public void blur(BlurEvent event) {
butChangeMe.setCaption("Disabled");
butChangeMe.setEnabled(false);
}
});
Button but = new Button("Change button", new ClickListener() {
private static final long serialVersionUID = -2235317499126190105L;
#Override
public void buttonClick(ClickEvent event) {
butChangeMe.setCaption("Enabled");
butChangeMe.setEnabled(true);
}
});
vlTestContent.addComponent(butChangeMe);
vlTestContent.addComponent(tf);
vlTestContent.addComponent(but);
(The second button is just for fun)
button.setVisible(false) will always work. You need to be careful to not fire up a another event on the focus lost event that ends up setting the visibility of the button to true.
You can request a repaint of a component or the whole window, but the whole point of the framework is that you will never need to do that, because visually modified components will automatically repaint on each request.
Just to be curious, do you let your request to finish before trying to see if the browser updates? Or you look at your browser right after you pass the setVisible() line in your debugger ?
I think that your point nr 2 happens because you clicked on the button, and what happens in this order is: 1st your focus lost event runs (which probably disables your button), 2nd button click runs and somehow a repaint is requested for that button because a state change happened in the button but a repaint show the warning that it won't do anything with it because it is disabled (was just disable by the focus lost event)
As a side note. I think this UI won't make for a good user experience, it should be the other way arround, if a validation is ok, then show the button (or better, always show the button, but enable/disable instead) But it depends...
So... Yeah.
I can't see the cursor in my game.
I've read here you have to place "this.IsMouseVisible=true;" somewhere in the main Game class constructor/initializer.
When I tried this, the "IsMouseVisible" wasn't recognized.
Any help?
Also: I've tried loading a texture for the cursor, follow the Mouse position and draw it, but with no success.
protected override void Initialize()
{
this.IsMouseVisible = true;
}
Maybe Initialize should do it? What exactly do you mean by "Not Recognized"
It always draw all focus elements , but it doesnt refresh the others until listfield is scrolled. That's only a problem in Blackberry 4.5 , 5.0 is ok.
I have tried to do the next before draw anything intoe the row :
public void drawListRow(ListField listField, Graphics graphics,int index, int y, int width)
{
listField.invalidate(); //My try
...
}
But it doesn't run .
Update
Ok , no invalidate().
I'll show you my problem better with an Image:
Thanks for reading . Any idea?
What your code snippet will do is every time one row is drawn, invalidate the entire field causing all visible rows to be redrawn, which will invalidate the entire field...
I hope some one at RIM thought of that and aborts the invalidate call. I can't give you any more ideas without more specific information about what you are doing with your user interface.