Using qooxdoo 5.0.2 (or previous version) I subclass a tablet widget and override _onKeyPress method.
Then, generating source I get a correct behavior, but with generate build the behavior is different.
I simplified my question, with this example below.
I subclass table widget and override _onKeyPress method WITH THE SAME CODE from qooxdoo 5.0.2 table widget source.
Run the example, edit a cell, and press enter.
Using
var tbl = new qx.ui.table.TableModified(tableModel)
the behavior is bad.
Using
var tbl = new qx.ui.table.Table(tableModel)
the behavior is correct.
If you put the example in a blank 5.0.2 project, using qx.ui.table.TableModified, you get a behavior if compile source, and another with compile build.
What is wrong with this? Where is my error?
Playground example
In qooxdoo there are, per convention, protected and private class members like methods or instance variables. Protected members start with an underscore like _myProtectedMethod, private members start with two underscores like __myPrivateMethod. The protected members are not affected by the build process and left as they are. This way they are override-able by derived classes.
Private members are obfuscated by the compiler to a random name, so that trying to access the private method or variable outside the class where they are defined leads to an exception.
In your playground example you've overridden the method _onKeyPress which per se is OK to be overridden as it is a protected member.
But within the overridden code you're using private members like this.__focusedRow which fails, because in the build version there is no more __focusedRow member as it got obfuscated. There are more private members in the code like __focusedCol, __selectionManager etc.
To successfully override the method, you have to replace those private members by their accessors, like this.getFocusedRow() instead of this.__focusedRow, this.getFocusedColum() instead of this._focusedCol etc.
Related
In my project I'm using C++/CLI and Windows Forms. I have two Forms. One is executed in main()
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);
Application::Run(gcnew FormA);
Another FormB is executed from the instance of FormA
FormB^ fb = gcnew FormB();
fb->Show();
I need to change components of FormB from FormA. Normally they are in private: section of class FormB. Is there any nice way to do that different from simply making them all public? In Native C++ I would use friend class but it's not allowed in C++/CLI.
C++/CLI has an access modifier that native C++ does not have. You are looking for internal:
Empowered by the strong support for modules in .NET. It is broader than friend but you have a pretty hard guarantee that whomever is messing with your private parts is never more than a few cubicles away from yours. Code that accesses internal members must be compiled into the same assembly. So your FormB class must be in the same project as your FormA class. The common case.
If you need the equivalent of friend across modules then you need the [InternalsVisibleTo] attribute. Exposing members with a public property would be another common way.
While providing public access to FormB's members may seem like a quick and easy solution, I would advise you to add some methods on FormB to perform said actions.
This way, you can call those methods from FormA, and at the same time retain proper encapsulation.
Hope this helps.
I've been researching ways to store global settings for my Android application and so far the best way seems to extend the Application class and store the shared data inside it, as described here. I've discovered that instead of using (CustomApplicationClass)getApplicationContext().getSomething() i can do the same thing by referencing directly to the static method inside the class like this: CustomApplicationClass.getSomething() and both ways work just fine.
Here's a piece from CustomApplicationClass:
public class CustomApplicationClass extends Application {
private static boolean something;
#Override
public void onCreate() {
[...]
}
public static boolean isSomething() {
return something;
}
public static void setSomething(boolean something) {
this.something = something;
}
}
Now, if i want to retrieve value of "something" variable somewhere in my code, say, from my application Activity, is there a difference between:
boolean var1 = ((CustomApplicationClass)getApplicationContext()).isSomething();
and
boolean var1 = CustomApplicationClass.isSomething();
? When running the application, both work fine. Is the second way safe to use, or is it inadvisable?
I've been researching ways to store global settings for my Android application and so far the best way seems to extend the Application class and store the shared data inside it, as described here.
Except that you're not doing that.
I've discovered that instead of using (CustomApplicationClass)getApplicationContext().getSomething() i can do the same thing by referencing directly to the static method inside the class like this: CustomApplicationClass.getSomething() and both ways work just fine.
Of course. You could just as easily had CustomApplicationClass extend Object, then executed CustomApplicationClass.getSomething(). You are gaining nothing by your current approach versus just using an ordinary singleton pattern in Java, and you are losing flexibility, as an application can only have one custom subclass of Application.
Is the second way safe to use, or is it inadvisable?
The first way is pointless, since your data member and methods are static.
Either:
Make your stuff in CustomApplicationClass not be static, and then use getApplicationContext().
Refactor CustomApplicationClass to not extend Application, and then use the static data member and/or accessor methods, or switch more formally to the Java singleton pattern.
Personally, I would go with option #2.
If you check the api of android.app.Application (http://developer.android.com/reference/android/app/Application.html) then you will find on Class Overview as following:
Base class for those who need to maintain global application state. You can provide your own implementation by specifying its name in your AndroidManifest.xml's tag, which will cause that class to be instantiated for you when the process for your application/package is created.
There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton.
I am a little bit confused right now...in the CakePHP documentation, it states that PHP's visibility can be replaced as follows: private with __ and protected with _. But doing the necessary replacements, and calling a private method from within another class leads to the execution of that method without any restriction. What am I missing?
If you're setting them in the model, just use private and protected, the _ and __ only work for controller actions
the underscore is only effective for controller method, since the user can't access it. Inside Cake app, it's really just a convention. Besides I don't think it's a problem: You only need to lock your house from outside, you don't need to lock every doors if you are the only one in it. If you want to achieve that use private and protected PHP keywords.
Using _ and __ for protected resp. private methods is a CakePHP convention because CakePHP (up to v1.3.x) is still a PHP4 framework and PHP4 doesn't have the protected and private keywords. This means, that even if you prefix your method names in such a way, they are still public methods as far as PHP is concerned.
In your application I would follow the approach used by the coming CakePHP 2: use the naming convention together with the respective visibility keyword. For example, a private method would then be defined as private function __myPrivateMethod().
I have a report which uses a custom assembly for purposes of localization/globalization.
I am creating my translation object (I'll call it "dictionary") and initializing a Dictionary property of this object in the custom code OnInit() override.
Everything works fine in report body, but when I try to reference the object I describe above in either the Report Header or Report Footer- it is not accessible (object ref is not set to instance of obj error..).
Can anyone either tell me why this is or how I might be able to workaround it? I really don't want to have to re-initialize this localization object separately for the Header and Footer. I was under the impression custom code class instances were accessible anywhere within the report definition.
Thanks in advance for any light anyone can shed on this.
I am not sure of your implementation, but the recommendation is to use static methods rather than instances. Understood that this is not always the best case for each design, but in your case, it sounds like you could use a static method and then in that case, when called from your header and footer, the custom assembly static method will initialize all data. It will be easier that putting the implementation or instance creation in the RDL.
This appears to just be by design. A custom class instance is not accessible to the Report Header or Footer. My solution was to simply add a check to the custom code function which the report expressions call (psuedo-code):
If IsNothing(myCustObj)
{
///initialize myCustObj
}
That seems to be the best workaround.
When using FxCop 1.36 for a WPF application with a single window that has yet to be modified, I get the InterfaceMethodsShouldBeCallableByChildTypes error with the following details:
Target : #System.Windows.Markup.IComponentConnector.Connect(System.Int32,System.Object) (IntrospectionTargetMember)
Resolution : "Make 'MainWindow' sealed (a breaking change if
this class has previously shipped), implement the method
non-explicitly, or implement a new method that exposes
the functionality of 'IComponentConnector.Connect(int,
object)' and is visible to derived classes."
Help : http://msdn2.microsoft.com/library/ms182153(VS.90).aspx (String)
Category : Microsoft.Design (String)
CheckId : CA1033 (String)
RuleFile : Design Rules (String)
Info : "Explicit method implementations are defined with private
accessibility. Classes that derive from classes with
explicit method implementations and choose to re-declare
them on the class will not be able to call into the
base class implementation unless the base class has
provided an alternate method with appropriate accessibility.
When overriding a base class method that has been hidden
by explicit interface implementation, in order to call
into the base class implementation, a derived class
must cast the base pointer to the relevant interface.
When calling through this reference, however, the
derived class implementation will actually be invoked,
resulting in recursion and an eventual stack overflow."
Created : 08/12/2008 22:26:37 (DateTime)
LastSeen : 08/12/2008 22:41:05 (DateTime)
Status : Active (MessageStatus)
Fix Category : NonBreaking (FixCategories)
}
Should this simply be ignored?
Ignore it, this is standard code that is in every WPF application and you don't see people complaining about net being able to call IComponentConnector.Connect from derived classes - so it's probably safe.
In general I think you should handle FxCop output as suggestions that have to be considered carefully, I've got a lot of bad advice from FxCop in the past.
Depends on what you expect an inheriter to do.
If you are not expecting this class to be inherited then it should be sealed and the problem goes away.
If you are expecting it to be inherited then you are taking the ability of the inheriting class to override the interface methods and still call them (i.e. base.methodname()). If that is your intent then you can ignore the warning.
However, that is not expected behaviour for inheritable classes so you should expose the interface publicly (i.e. An implicit interface instead of an explicit interface).