Dynpros directly by methods

[former_member1161170]

I have just read this interesting article, written by Thomas Jung:

"OO ABAP Dynpro Programming"

/people/thomas.jung3/blog/2005/09/08/oo-abap-dynpro-programming

If I have understood well:

1) I can't use dynpros directly by methods

2) Thomas suggests to get a dynpro by a function module, and after he can use the dynpro calling the function module

3) It isn't the faster technique (I could get everything only by the function module, without a class), but he suggests it only to get more excercises as it possible.

Are these three things correct?

Or it is possible to use dynpros directly by methods?

[former_member1161170]

I have just read this interesting article, written by Thomas Jung:

"OO ABAP Dynpro Programming"

/people/thomas.jung3/blog/2005/09/08/oo-abap-dynpro-programming

If I have understood well:

1) I can't use dynpros directly by methods

2) Thomas suggests to get a dynpro by a function module, and after he can use the dynpro calling the function module

3) It isn't the faster technique (I could get everything only by the function module, without a class), but he suggests it only to get more excercises as it possible.

Are these three things correct?

Or it is possible to use dynpros directly by methods?

[Former Member]

Hi,

1) that is only correct für global classes (the ones you define with the class builder), local classes can use dynpros

directly with commands like "call screen"

2) it is a common workaround for global classes, yes

3) you could. nobody says you have to develop with oo-techniques, you can achive the same results by using classic abap

or a mixture of abap-oo and classic abap. on the otherhand. maybe check out this article about abap oo. http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/37c5db90-0201-0010-3a9b-d0a5288f3...

i agree with you that its not a good style to use a function module in oo-programming. but the classis sap gui is based on dynpros and has come a long way. for example webdynpro is completely "pure oo".

greetings,

dsp

[former_member1161170]

>1) that is only correct für global classes (the ones you define with the class builder), local classes can use dynpros directly with commands like "call screen"

Yes. I'ts my case I'm making a global class by se24 / se80.

>2) it is a common workaround for global classes, yes

>3) you could. nobody says you have to develop with oo-techniques, you can achive the same results by using classic abap or a mixture of abap-oo and classic abap. on the otherhand. maybe check out this article about abap oo.

I'm new in Abap: I knew Java before Abap so now, if it is possible, i prefer Abap OO than Abap classic. But when I find tis limits I'm discouraged.

The article is very interesting.

i agree with you that its not a good style to use a function module in oo-programming. but the classis sap gui is based on dynpros and has come a long way. for example webdynpro is completely "pure oo".

I must work by 4.6c. I'm sure that Web Dynpros are very interesting, but they're only a dream this year.

Thanks.

Grettings.

[Former Member]

hi,

im in the same situation. i developed oo before i reached the apap world, so i was quite used to this coding-stylet. sadly there are several points where you need to go back and use classic abap elements.

maybe you could just write a small local class für dynpro handling and keep on using your global class, but i never tried this.

greetings,

dsp

Edited by: dsp on Apr 22, 2010 12:00 PM

[sebastianNoe]

Hi,

I am currently working with Dynpros in an OO context as well.

For me it was fine to define a global Interface and build up on this Interface a local class which works as a "Dynpro Handler". So my global classes can actually access the Dynpro environment and I do not have to code that much non OO Code.

Kind Regards,

Sebastian

[Former Member]

Hi,

thats a really great idea, ill try this out in my next project.

[former_member1161170]

> I am currently working with Dynpros in an OO context as well.

> For me it was fine to define a global Interface and build up on this Interface a local class which works as a "Dynpro Handler". > So my global classes can actually access the Dynpro environment and I do not have to code that much non OO Code.

In practice it doesn't seem very different, but the style is certainly better.

I'll try to do it