Question:
Guys,
When tesing a program I often get fed up with running the program and then choosing the variant required to best test with. When running your code many many times this can often get really laborious.
I currently use this code (which I remove before transporting):
The aim of this code was to bypasss the process of continually identifying a variant when testing from withing SE38/80. I tend to develop in SE80 nowadays, make code changes, activate, execute and then test the results, repeating this process until I'm happy.
Having Executing the code I was continally pressing the Variant icon, waiting for the list of variants to display, then choosing one and then executing [F8].
Now I can just make my changes, activate and then hit F8 twice...
Dr Sidewalk
You could define a transaction which starts your report with a predefined variant. It does not make a big difference to call the report via the transaction from se80 and it has the advantage that no coding need to be removed.
Christian
Answer:
have a look a FM RS_VARIANT_EXISTS and RS_SUPPORT_SELECTIONS
Answer:
Both of two above transactions assume that you know what the transaction for the report is, which I don't, or wish to.
The aim, as I mentioned, was to be able to set a single variant (I don't care what it's called) against a report being tested so that when I run it within SE38/80 it defaults the selection-screen variants automatically, I just have to hit F8 twice.
With the exception of making the code inserted into the INITIALIZATION event into a user function I can't think of anything else that could be inproved and still achieve the original aim.
Creating a transaction and adding a defaulted variant just makes the above testing process laborious, especially as it will exit the editor.
Dr Sidewalk
_________________
"In the middle of difficulty lies opportunity" - Albert Einstein
"Money isn't everything in life, unless you don't have it". David King
"Fail to plan, plan to fail"
"Success is a journey, not a destination."
Answer:
If you are wroking in SE80 (I mean with object hierarchy in the left pad) then you'll see the transaction connected to the report being edited.. And executing transaction costs a couple of right mouse click (opening object tree to the transaction, then local menu for transaction, then executing transaction).. No variant selection dialog. Is it so laborious? You do not have to exit editor. Hope this helps, except you are working in 4.0 .
_________________
Best regards, Sergey Korolev
Answer:
Nice idea, dr.
Being so lazy , you could also avoid the double F8 pressing.
Both of two above transactions assume that you know what the transaction for the report is, which I don't, or wish to.
The aim, as I mentioned, was to be able to set a single variant (I don't care what it's called) against a report being tested so that when I run it within SE38/80 it defaults the selection-screen variants automatically, I just have to hit F8 twice.
With the exception of making the code inserted into the INITIALIZATION event into a user function I can't think of anything else that could be inproved and still achieve the original aim.
Creating a transaction and adding a defaulted variant just makes the above testing process laborious, especially as it will exit the editor.
Dr Sidewalk
Nothing beats the double click on F8...
My point was that I do not feel very comfortable concerning the fixed coding which has to be removed before it can be transported to the productive system. On the other hand I do not see much harm that could be caused that way.
To be more on the save side you could define a subroutine pool and call the coding via an external perfom with the if exists option.
As long as you do not transport the subroutine pool you could easily add that perform to any of your reports and there will be no effect if the coding is not removed before transporting into the productive system
Christian