I am trying to employ a custom renderer for my Picker controls. I also need my Picker to fire up when I open a tab. I do this by calling the picker's Focus() method on tab SelectionChanged.
if (e.NewPosition == 1)
{
myPicker.Focus();
}
This, however, fires up two instances of the picker alert at the same time; one is the default renderer, the second one is my custom renderer. They are one atop the other, such that when I close the one with my custom renderer, the one with default renderer is visible.
Simply tapping the Picker will display only one instance, with the custom renderer (this works as intended).
I wrote my custom renderer following this post's answer.
I tried the answer described here, but the problem is that this skips over the second instance of the picker, which is not what I need. I need to keep the instance that has my custom renderer, not the one with the default renderer.
I also tried to make sure that I am running on the right thread, implementing code described in this question's answers.
Moreover, I tried to somehow remove events from the CustomRenderer and add them again, like this:
protected override void OnElementChanged(ElementChangedEventArgs<Xamarin.Forms.Picker> e)
{
base.OnElementChanged(e);
Control.Click += null; // hoping this would override all existing events
Control.Click += Control_Click;
}
Finally, this question came closest to my situation and I tried following the solutions described in the answers.
None of these worked. I believe that when Focus() is called, somehow the default renderer shows up first due to my custom renderer inheriting the default PickerRenderer.
How do I enforce the custom renderer?
Or is there a different way for me to fire up my picker upon changing tabs, instead of calling Focus()?
My project runs on Xamarin.Forms 5.0.0.2545 (latest version as of when I'm writing this question).
EDIT
I observed the following behaviour: Control.Click event is fired AFTER the default renderer is displayed. By debugging the app and placing a break point inside my Control.Click handler function, I can see that the app first opens the default picker, and then it halts in said breakpoint.
SOLVED
By studying the PickerRenderer.cs class, I realised that there were more functions that had to be overwritten.
To begin with, I made my custom renderer class implement the IPickerRenderer interface and added the following function:
void IPickerRenderer.OnClick()
{
Control_Click(this, null); // this function handles the Control.Click event
}
Moreover, I overwrite the CallOnClick() function:
public override bool CallOnClick()
{
Control_Click(this, null); // same function, that handles the Control.Click event
return true;
}
Finally, I added this bit of code (thanks to this answer) that ensures the Picker shows up only once. Thus, my OnElementChanged function looks like this:
protected override void OnElementChanged(ElementChangedEventArgs<Picker> e)
{
base.OnElementChanged(e);
if (Control != null)
{
Control.Focusable = false;
}
Control.Click += Control_Click; // this is where I link the handler to the event
}
The conclusion is that the described behaviour either
wasn't a bug, which means I just hadn't implemented it correctly
was a bug, and I managed to find a good workaround
Either way, I managed to solve my problem.
If anyone else stumbles upon this, I hope my work helps.
Related
I'm currently doing some cross-platform mobile development through Visual Studio using Xamarin (so in C#) and am about to start the iOS portion. I've never done iOS development before and thought I could get myself acquainted with their "Hello, iOS" Tutorials. Unfortunately, things have not been going smoothly. I constantly get NSInvalidArgumentExceptions from my TouchUpInside actions:
Foundation.MonoTouchException: Objective-C exception thrown.
Name: NSInvalidArgumentException Reason:
-[ViewController TranslateButton_TouchUpInside:]:
unrecognized selector sent to instance 0x7b6200d0
I can occasionally remedy it for a moment by literally remaking the Buttons, but it breaks pretty much right afterwards. The actual error itself occurs in my Main.cs file:
using UIKit;
namespace CheckinIOS
{
public class Application
{
static void Main(string[] args)
{
UIApplication.Main(args, null, "AppDelegate"); //this line is where it breaks
}
}
}
In case it is any helpful, I am trying to deploy to iPhone 5S simulator running iOS 9.3 (but it breaks on iPhone 6 simulator as well). I could also post more of my code if necessary, but I copypasted all the C# from Xamarin's tutorial, and did the same thing as them for Main.storyboard.
I have spent a while looking for people with the same problem as me, but their solutions either did not work, or they got the error for slightly different reasons. Any assistance is appreciated.
EDIT: Here is my implementation of TranslateButton_TouchUpInside:
TranslateButton.TouchUpInside += (object sender, EventArgs e) =>
{
// Convert the phone number with text to a number
// using PhoneTranslator.cs
translatedNumber = PhoneTranslator.ToNumber(PhoneNumberText.Text);
// Dismiss the keyboard if text field was tapped
PhoneNumberText.ResignFirstResponder();
if (translatedNumber == "")
{
CallButton.SetTitle("Call", UIControlState.Normal);
CallButton.Enabled = false;
}
else
{
CallButton.SetTitle("Call " + translatedNumber, UIControlState.Normal);
CallButton.Enabled = true;
}
};
The iOS Runtime is looking for a method called (in Obj-C land) TranslateButton_TouchUpInside: in your ViewController class. However there is no method exported to Obj-C with that name. A first guess is that you added an event to the button in the storyboard that perhaps had that name, but you either deleted that method or never implemented it.
Try opening your storyboard in iOS Designer and removing any event from the Properties->Events tab when your button is selected on the canvas. Also I assume your button has the name TranslateButton in the Properties->Widget pane when the button is selected on the canvas.
There are a couple ways to attach events to controls in Xamarin iOS. One, and the preferred way, is to create an event in iOS Designer for the control. If you do this, a partial method stub will be in the .designer.cs file with an Export attribute that exports the method name to the Obj-C runtime. You will then need to implement this method, using the same signature (without the Export Attribute), in your main .cs file for the ViewController. This is called, in Obj-C land, an action.
The other way is to do as is shown in your code snippet. In this case you ONLY need to give the control a name in the Properties->Widget pane that you can then use in code to subscribe to the TouchUpInside event. This is called, in Obj-C land, an outlet.
My guess is that you did both but without ever implementing the TranslateButton_TouchUpInside: method in your ViewController. Note that this is the Obj-C name used in the Export attribute of the method stub created in the .designer.cs file when you add an event to a control.
But it is hard to say without seeing the storyboard and both the main ViewController.cs file and the ViewController.designer.cs file
I am having a rather odd problem with the Gecko Webbrowser control, I have created my own class which inherits off of the Gecko Webcontrol and within the constructor of this I have set an event:
class fooGeckoClass: Gecko.GeckoWebBrowser
{
public fooGeckoClass()
{
this.DomClick += new EventHandler<Gecko.GeckoDomEventArgs>(fooEventFunction);
}
private static void fooEventFunction(Object sender, Gecko.GeckoDomEventArgs e)
{
((Gecko.GeckoWebBrowser)sender).Navigate("www.foo.com");
}
}
I am using three of these controls in a manually created UserControl, the controls are loaded in dynamically at start up from a config file and added the the UserControl controls collection. When clicking on any of the three controls, all three will navigate to "www.foo.com" away from there original site. I had a look at:
e.StopPropagation();
Which specifies that it stops further propagation of events during an event flow, however it does also specify that it will handle all events in the current flow, I believe the events must have already been given to the controls before this has a chance to stop it as the the three controls will still fire the event. I also tried e.Handled = true to no avail. Has anyone encountered this problem before and have any kind of solution to make it only fire on the control that was clicked on?
EDIT:
It may be worth showing how the controls are added to the form seeing as this must be where the problem is occurring (it does not happen if the controls are just placed in a user control in a small test app).
private void fooUserControl_Load(object sender, EventArgs e)
{
if (!this.DesignMode)
{
for (int iControls = 0; iControls < geckObs.Count(); iControls ++)
{
fooGeckoClass geckControl = new fooGeckoClass();
this.Controls.Add(geckControl );
break;
}
}
}
Odd answer but I seem to have resolved the issue, DomClick was being called at first run, changing to DomMouseClick or DomMouseUp has completely resolved the issue. I assume DomClick must be an event unto itself as it also doesn't use the GeckoDomMouseEventArgs but the regular GeckoEventArgs.
EDIT:
To add to this, the site I was going to was actually calling DomClick when it had finished loading hence the reason it was being called at start up across all three browsers.
I have a winform app that we use in house. It has many individual controls on each of it's 25 "pages"(usercontrols). Our user base prefers very technicolor apps...they want a TextBox to be outlined Blue if it is a required field (color should go away if data entered). They want a TextBox to change to outlined Green if data has been changed in it to remind them to save. They want a currently highlighted TextBox to be outlined RedOrange.
I have been trying to come at this from many different angles (some of you have probably seen similar posts by me lately). Non of them work... So one way I KNOW will work is to register the paint event for every control and check for a "required" tag for the required portion. The OnFocus for the current field portion and finally the Validate event for the data changed portion.
I know this is not the best way or at least I STRONGLY suspect it isn't but I am out of time, nearly, and nearing my point of frustration. That being said, will that DESTROY my app's responsiveness? Is there a better way? Can I override the base control to color on different premises so that I don't have to go to each of the 100+ controls?
Any idea would be welcome because I am between my stupid Paint_Event idea and rewriting all the controls in WPF... :)
I will be rewarding a solution that works for me and that I can implement shortly with a Bounty.
I am so sick of colors...
Here is my attempt based on suggestions.
public class MyTextBox : TextBox
{
private bool _isRequired;
public bool isRequired
{
get
{
return _isRequired;
}
set
{
_isRequired = value;
}
}
protected override void OnPaint(PaintEventArgs e)
{
base.OnPaint(e);
if (isRequired && base.Text.Equals(string.Empty))
{
HighlightControl(e.Graphics);
}
}
private void HighlightControl(Graphics graphics)
{
ControlPaint.DrawBorder(
graphics,
this.ClientRectangle,
Properties.Settings.Default.RequiredFieldColor,
Properties.Settings.Default.BorderWidth,
Properties.Settings.Default.BorderStyle,
Properties.Settings.Default.RequiredFieldColor,
Properties.Settings.Default.BorderWidth,
Properties.Settings.Default.BorderStyle,
Properties.Settings.Default.RequiredFieldColor,
Properties.Settings.Default.BorderWidth,
Properties.Settings.Default.BorderStyle,
Properties.Settings.Default.RequiredFieldColor,
Properties.Settings.Default.BorderWidth,
Properties.Settings.Default.BorderStyle);
}
}
I don't know the particulars of your app, but you could derive your own control from the base TextBox and let it handle much of this for you. Some thoughts:
Give it a bool Required property and some internal logic to color accordingly.
Have the textbox respond to its own
events - when text is entered, it can
do the right thing - change colors or
whatever is appropriate.
Provide your derived control with
properties to set the colors that get
used for each condition, then you can
switch them easily when the users
decide they want pink rather than
green.
You can utilize the focus events to "know" whether your TextBox (this is the one control you mentioned, so I'll assume this is the main control used here) has focus or lost it and the text change events can be used to drive all the color changes to the control.
You can certainly wire up all the
text boxes to control the
Apply/OK/whatever buttons to
determine if the buttons should be
enabled, assuming you have an Apply button or something like that which stores the data on click. There are a number of ways to communicate this. It's easy enough to iterate through the controls and ask their state.
Seems like this would work just fine.
What have you tried? You didn't really mention what you'd tried that didn't work.
You've got a problem, TextBox is, erm, special. Windows Forms leaves all painting to the native Windows EDITBOX control, the Paint event won't be raised. That can be fixed by setting the UserPaint control style to true:
using System;
using System.Drawing;
using System.Windows.Forms;
class MyTextBox : TextBox {
public MyTextBox() {
this.SetStyle(ControlStyles.UserPaint, true);
}
protected override void OnPaint(PaintEventArgs e) {
base.OnPaint(e);
// Paint something
//...
}
}
Copy and paste this into a new class, compile and drop the new control from the top of the toolbox. Try it out, you'll be quite disappointed. What you see is the result of close to 20 years of appcompat hacks on a control that dates back to Windows version 2. One of the grave crimes that EDITBOX commits is painting itself without generating a WM_PAINT message. That was important way back when Windows had to run on a 386SUX, keeping it compatible with old programs prevented Microsoft from fixing its behavior.
No happy answers here, you'll have to give up on the idea of customizing the border. What you can do is give the control a distinct BackColor when it has the focus. For example:
class MyTextBox : TextBox {
Color mBackColor;
protected override void OnEnter(EventArgs e) {
mBackColor = base.BackColor;
base.BackColor = Color.AliceBlue;
base.OnEnter(e);
}
protected override void OnLeave(EventArgs e) {
base.BackColor = mBackColor;
base.OnLeave(e);
}
}
You can inherit from base control classes and add your own drawing logic. That won't be very expensive performance-wise, but, if your app is of significant size, you'll have to replace each occurence of standard TextBox with your own implementation.
C# 3.5 Winforms...
So I’ve recently discovered the IExtenderProvider and how it can be used to extend controls with additional properties.
In a prototype project that I setup i put a break point on the ‘set’ method for my extendee property and as the form loads I could see the ‘set’ method executing for every control on the form; which is exactly what I wanted. Following the successful prototype I implemented the extender component into my main project. All the forms in my project inherit from a base form which I’ve added my extender component to. On the base form I set the modifier of the extender component to public so that its accessible by the form inheriting this base form.
Doing the same thing before i added a break point on the ‘set’ method for my extendee property but the method doesn’t execute for the controls in the form (but only for the controls in the base form). HELP!
I should probably add at this point that i’ve source controlled my forms and so most of them are checked-in (ie lock from modification). For the forms that I’ve checked out and modified the provider property; I’ve noticed in the designer file that all controls have an additional statement which calls the ‘set’ method of the provider property.
this.MyProvider1.SetMyProperty(this.txtTextBox1, false);
Am I right in thinking that for the extender component to work it has to physically modify the designer file or should it be able to cope with locked files and therefore call the set method dynamically? I guess if it does have to modify the designer file then this isn’t a problem for new forms or forms that get modified after the extender component was added to the project – but it would be problem when you have 101 forms all locked by source-safe...
I’d appreciate any thoughts...
At what point does the extender provider (IExtenderProvider) extend the 'type' (in my case a winforms control) that the extender was intended for; at design time or at run time?
The designer is responsible for showing you the properties of the extender in the property editor
Method bool CanExtend(object) from the IExtenderProvider interface
Am I right in thinking that for the extender component to work it has to physically modify the designer file or should it be able to cope with locked files and therefore call the set method dynamically?
It has to physically modify the designer file, and write the extended properties there
I guess if it does have to modify the designer file then this isn’t a problem for new forms or forms that get modified after the extender component was added to the project – but it would be problem when you have 101 forms all locked by source-safe...
This is is not a problem for new forms, and not for old forms.
If you want to set some extended properties, open the old form and set the extended properties (a check out of the file is necessary)
This really does confirm my suspicions, many thanks. But this does leave a problem in that the components are only extended if some physical change is made to the old form.
I was trying to hijack the Set property method to also add and remove an event handler to the component (if the component was a control). Image the property is a Boolean and when set to false it adds the event handle and therefore the default behaviour (setting to true doesn’t add and event handler)
To cut a long story short the controls which were part of newly added forms automatically have an event handler added even without me explicitly setting the property to false but the designer file of the old forms never modifier so the event handler wasn’t added.
As some background, I was trying to add a global event handler for all controls
Global event handler for all controls for User Help
The theme here is to add context help to my forms here’s example of the extender ( the event handler is added as part of the end initialiser)
public partial class HelpProvider : Component, IExtenderProvider, ISupportInitialize
... other code of the extender omitted ...
#region ISupportInitialize Members
public void BeginInit()
{
// do nothing
}
public void EndInit()
{
if (DesignMode)
return;
foreach (Component item in _disableOnlineHelp)
{
if (item == null)
continue;
if (GetDisableOnlineHelp(item)) // developer has decide to set property to TRUE
continue;
Control control = item as Control;
if (control != null)
continue;
control.HelpRequested += new HelpEventHandler(HelpProvider_HelpRequested);
_toolTip.SetToolTip(control, GetHelpText(control));
}
}
#endregion
#region DisableOnlineHelp Provider Property
public virtual bool GetDisableOnlineHelp(Component component)
{
object flag = _disableOnlineHelp[component];
if (flag == null)
return false;
return (bool)flag;
}
public virtual void SetDisableOnlineHelp(Component component, bool value)
{
_disableOnlineHelp[component] = value;
}
#endregion
One issue might be the foreach loop in the EndInit method:
Control control = item as Control;
if (control != null)
continue;
If the item is, in fact, a Control, you get out of the loop before executing this code:
control.HelpRequested += new HelpEventHandle(HelpProvider_HelpRequested);
_toolTip.SetToolTip(control, GetHelpText(control));
so you never add the Event Handler or the ToolTip, to any Control. Oops :)
Thanks,
John
I have an owner-drawn UserControl where I've implemented double-buffering. In order to get double-buffering to work without flicker, I have to override the OnPaintBackground event like so:
protected override void OnPaintBackground(PaintEventArgs e)
{
// don't even have to do anything else
}
This works great at runtime. The problem is that when I have an instance of the control on a form at design time, it becomes a black hole that shows trails of whatever windows are dragged over it (because the override of the OnPaintBackground event also governs design-time appearance). It's just a cosmetic problem, but it's visually jarring and it always leads new developers on the project to assume something has gone horribly wrong.
Is there any way to have an overridden method like this not be overridden at design time, or is there another solution?
Steven Lowe's solution unfortunately cover all scenarios, espcially when user controls come into the picture.
The this.DesignMode flag is very deceptive. Its only scope is to check if the direct parent is within the designer.
For instance, if you have a Form A, and a UserControl B, in the designer:
A.DesignMode is true when viewed in designer
B.DesignMode is false when viewing A, but true when looking directly at B in the designer.
The solution to this is a special flag to check (sorry for the ugly C++ code):
if(this->DesignMode ||
LicenseManager::UsageMode == LicenseUsageMode::Designtime)
return;
This variable will always show the proper design boolean.
if (this.DesignMode)
{
return; //or call base.OnPaintBackground()
}
The solution of greggorob64 in C#:
if (DesignMode || LicenseManager.UsageMode == LicenseUsageMode.Designtime)
{
return;
}