I wanna change my titlebar in a dynpro when a specific class method is triggered. So I thought I could call a function in my report, where my dynpro is located, which changes uses the 'SET TITLE' to change the titlebar content.
Is this possible and how exactly? Or is there even a better way?
Thanks!
Use SET TITLEBAR during the PBO processing - it doesn't matter if it is used from a method, a FORM or the module directly. I'd recommend having one single SET TITLEBAR statement that is always called at the same point in the control flow instead of littering the code with SET TITLEBAR statements for better maintainability.
Recently I needed to implement something similar so I defined a class hierarchy where I created an abstract class with a method 'CALL_DYNPRO'. This method is intended to load an specific dynpro in the concrete classes.
So, depending on an action I defined internally I generate the appropriate instance and then the method 'CALL_DYNPRO' loads the dynpro I created with their own gui statuses and titles.
The following is more or less the code I created.
********************************* The abstract class
class lc_caller definition abstract.
public section.
methods: call_dynpro.
endclass.
class lc_caller implementation.
method call_dynpro.
endmethod.
endclass.
********************************* The concrete classes
class lc_caller_01 definition inheriting from lc_caller.
public section.
methods: call_dynpro redefinition.
endclass.
class lc_caller_01 implementation.
method call_dynpro.
call screen 101.
endmethod.
endclass.
class lc_caller_02 definition inheriting from lc_caller.
public section.
methods: call_dynpro redefinition.
endclass.
class lc_caller_02 implementation.
method call_dynpro.
call screen 102.
endmethod.
endclass.
********************************* Factory
class caller definition.
public section.
class-methods call importing i_type type char01
returning value(r_instance) type ref to lc_caller.
endclass.
class caller implementation.
method call.
data: caller1 type ref to lc_caller_01,
caller2 type ref to lc_caller_02.
case i_type.
when '0'.
create object caller1.
r_instance = caller1.
when '1'.
create object caller2.
r_instance = caller2.
when others.
endcase.
endmethod.
endclass.
start-of-selection.
data obj type ref to lc_caller.
obj = caller=>call( '0' ).
obj->call_dynpro( ).
This is the code inside the PBOs.
Dynpro 101
module status_0101 output.
set pf-status 'FORM1'.
set titlebar 'VER'.
endmodule.
Dynpro 102
module status_0102 output.
set pf-status 'FORM2'.
set titlebar 'TRA'.
endmodule.
If tomorrow I need to call another dynpro I create it and then code the concrete class to load it.
Very straightforward and works very nice.
Hope it helps.
Related
How does a main method gets called in scala ? Why does a main method gets called in when it is written only in object but not in class ?
Because the specification says so:
A program is a top-level object that has a member method main of type (Array[String])Unit. Programs can be executed from a command shell. The program's command arguments are passed to the main method as a parameter of type Array[String].
The main method of a program can be directly defined in the object, or it can be inherited.
It speaks only about top-level objects, not classes. If you define a main method in a class, then it will be just an ordinary method that you can invoke on the instances of this class. Unless you define a top-level object that inherits the main from this class / trait, this method called main will not be treated as an entry point of the application.
The main method must be a static method. In Scala to create a static method you put it in an object. Methods in a class are not static.
In the scala language they decided to separate class, which hold only instance behavior and state, and object which hold static behavior and state. This is different from java where classes hold both instance and static members where something is made static using the static keyword.
It is because in scala the only way to define a method static is object class. And also it is necessary only one instance of main class is created , not multiple instances. That's why it is object class
Why do I have class or interface passed as a method parameter in a class? I don't get that concept. For example:
Declaration:
public void doSomething (Class yourClass){}
Calling the method:
doSomething(yourClass);
What is the benefit? Is there an alternative? I can't call methods for yourClass anyway, for example: doSomething(yourClass.someMethod()) or doSomething(yourClass) and then yourClass.someMethod() are both invalid.
There's several possibilites, depending on the particular language. doSomething(Class) could...
Instantiate and return a Class generator.
Create an object or service to track or otherwise interact with one or more Class objects.
Return useful information about Class (e.g. via reflection).
How can I access a super class' method from a child class' method?
Here is an example that illustrates the problem:
Lets say, we have two classes
class parent definition.
public section.
methods f.
endclass.
class child definition inheriting from parent.
public section.
methods f redefinition.
methods g.
endclass.
Now, in the implementation of g we want to call the super class' implementation of f similar to the following syntactically wrong snippet
class child implementation.
method g.
super->f( ). "forbidden: super-> can only be used to call the previous implementation of the same method
endmethod.
endclass.
As stated in the comment, it is not possible to use super->. Can you help?
After some googling, it was suggested to copy the implementation of parent->f into child->g is this really the only way to do it?
The actual use case
#vwegert asked why f is redefined in the first place. In my real use case, parent is a view, and child its extension. child->f is an event handler which is supposed to trigger a popup. child receives a callback when the popup closes in form of a call to g. If g is called, the original implementation parent->f should be called.
You will have to resort to some rather ugly workaround - like set a flag (attribute of the object) in g, then call the redefined f, check whether the flag is set and if it is, only call super->f. It sounds like a very broken design, though. You don't go into details, but I assume you're not able to change the parent view - otherwise I'd strongly suggest to re-think the design because this will lead to unnecessary complexity and technical debt that will very likely introduce bugs and increase maintenance cost.
If you do not mind creating a protected method do_f in the parent class and then delegating the control from f method to do_f method in it. Then the following solution could be quite a neat one. No code duplication, only some additional work in delegating the call in the "original" f method.
REPORT zzy.
CLASS parent DEFINITION.
PUBLIC SECTION.
METHODS f.
PROTECTED SECTION.
METHODS do_f.
ENDCLASS.
CLASS parent IMPLEMENTATION.
METHOD f.
do_f( ).
ENDMETHOD.
METHOD do_f.
WRITE / 'Parent''s f'.
ENDMETHOD.
ENDCLASS.
CLASS child DEFINITION INHERITING FROM parent.
PUBLIC SECTION.
METHODS:
f REDEFINITION,
g.
ENDCLASS.
CLASS child IMPLEMENTATION.
METHOD f.
WRITE / 'Child''s f'.
ENDMETHOD.
METHOD g.
do_f( ).
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
DATA(lo_child) = NEW child( ).
lo_child->g( ).
lo_child->f( ).
I have a C# class called MyCustomRuleTemplate which is inherited from Ektron.Cms.Content.Targeting.Rules.RuleTemplate class. In that I have added a constructor such as below
public MyCustomRuleTemplate(): base("someKey")
{
//Some code here
}
Its working fine without any error. If I given it as
public MyCustomRuleTemplate()
{
//Some code here
}
Im getting error like 'Ektron.Cms.Content.Targeting.Rules.RuleTemplate' does not contain a constructor that takes 0 arguments.
Can anybody help me to know why it is?
The reason you are seeing "does not contain a constructor that takes 0 arguments" when instantiating your class object using the second constructor is because when you call your constructor, c# tries to call the constructor on the base class as well, which in this case takes a parameter.
See this post on msdn:
http://msdn.microsoft.com/en-us/library/ms173115%28v=vs.80%29.aspx
Key parts:
"In this example, the constructor for the base class is called before the block for the constructor is executed. The base keyword can be used with or without parameters. Any parameters to the constructor can be used as parameters to base, or as part of an expression. For more information, see base.
In a derived class, if a base-class constructor is not called explicitly using the base keyword, then the default constructor, if there is one, is called implicitly."
And: "If a base class does not offer a default constructor, the derived class must make an explicit call to a base constructor using base."
When running FxCop I get the error that interface methods should be callable by child types.
The resolution states the following:
"Make 'MenuPreview' 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."
I get this for all classes the derive from Window or some other UI class. Is this a red herring that I can ignore, or is there something I should be doing?
I think the issue is that if an interface is implemented explicitly, it will be impossible for a derived class to both change the interface behavior and make use of the base-class behavior. A common pattern to get around this difficulty in cases where explicit interface implementation would be required is to have the interface do nothing but call a protected virtual method, and have any derived classes that wish to override the behavior of the interface do so by means of the protected virtual method.
Consider IDisposable.Dispose(). If the code in an explicit implementation were actually responsible for performing the disposal, there would be no way for a derived class to add its own dispose logic except by reimplementing IDisposable, and there would be no way for a class which reimplemented IDisposable to access its parent's Dispose method. Although Microsoft could have had IDisposable.Dispose call a protected function with a different name, it opted to use the same name but add a dummy parameter of type Boolean.