data sort qf removes all data statements

[AndreaBorgia-Abo]

I'm creating an old school wizard, so we have a function group, function module, top include, the usual suspects. The top include had concatenated data statements, so first I applied the the split qf which worked ok. Saved, activated (not really necesssary, just mentioning it).

Next I tried the "sort" qf: all the data statements are gone and the status line has this message: Quelltext nicht formatierbar. Modularisierungseinheit nicht gefunden (I'm logged in in German, a rough translation should be "Source text cannot be formatted. Modularization unit not found")

I'm fine with reverting the changes immediately if I notice the qf went awry, but I wonder if it could be made to work in this context or at least blocked if the fix is not possible.

[fidley]

Hi Andrea, I will work on this today evening. Seems my last updates were solving one bug, and creating next one.. Cheers

[fidley]

Please update the plugin and try again.

[AndreaBorgia-Abo]

Updated, restarted, tried both single and combined: some statements survive but most don't

[fidley]

Damn, can you post your code here? Somehow I cannot reproduce it

[fidley]

[AndreaBorgia-Abo]

I'm not sure I can, actually, so I'll have to try and reproduce the issue at home (assuming the Wizard generator is available in one of the MiniSAPs). In the meanwhile, is there some trace that I can generate and send it over to you?

[fidley]

just copy this what you selected for sorting xD and paste here.

You can also try to do again an update

[AndreaBorgia-Abo]

Updated, no changes, here is the code:

DATA gf_bed_old      TYPE /softw/tadsdef08-clsname. "Source condition class
DATA gf_db_old       TYPE /softw/tadsdef08-clsname. "Source data class
DATA gf_qint         TYPE fpcontext-interface. "Source Adobe interface
DATA gf_zint         TYPE fpcontext-interface. "Target Adobe interface
DATA gf_qform        LIKE /softw/tadsdef12-formname. "Source Adobe form
DATA gf_zform        LIKE /softw/tadsdef12-formname. "Target Adobe form
DATA gr_wiz_form_cop TYPE REF TO /softw/cl_ca_ads_wiz_form_cop. "Utility class from FormcopyV2
DATA gf_appl         LIKE /softw/vadsatt01-appl. "Source application
DATA gf_qmod         LIKE /softw/vadsatt01-modul. "Source module

data: gf_mod_check type c.
data: gf_applflag type c.
data: gf_zmod like /softw/vadsatt01-modul. "Target module
data: gf_appl_neu like /softw/vadsatt01-appl. "Target application

data: gs_env10 type /softw/tadsenv10.

data: gs_lay04 type /softw/tadslay04.

data: gf_cb_nolayout type c value abap_true.

data: gf_z_layoutdescr type /softw/ads_layoutdescr.
data: gf_z_adslayout type /softw/tadsdef01-adslayout.

data: gf_answer type c. "Popup answer

[fidley]

Thanks. I'm afraid I can't find the reason for your issue. Maybe it's something with the comments? I've pushed now some changes, so the inline comments should be at least partially handled in the sorting QF.

Or maybe @lukas-mb can help? He added this part, so maybe he had such behaviour as well?

[lukas-mb]

That is strange. I can't reproduce it either...

I tested all versions 1.1.6.XXX and it works smoothly except the latest one (1.1.6.202406181410). Here I get an extra comment at the end, but the sorting still works:

[AndreaBorgia-Abo]

Thanks for checking, seems I am the only one experiencing this issue. Is there a way to trace what is going on? Maybe writing a tracelog that I can attach?

[fidley]

@lukas-mb the "last comment" bug I can see as well.... I need to rethink how to handle this. Normally when you have the AbapStatement it begins where the previous one ends. So in the case of your example the DATA: gf_answer type C. ends at dot, while comment is assigned to next one. Normally I can change that the statement ends after the inline comment, but then all (most) exisitng quick fixes will stop to work correctly as dot or comma will be included into AbapStatement. Give me some time to fix it. I'll create a bug from it.

If I remember correctly, previously all comments were deleted during sorting

@AndreaBorgia-Abo the easiest way for us to check would be if you would clone the repo into your Eclipse and then you would run it in debug mode. I could lead you through that process once you have it in your installation. Or a session with remote control could be helpful so I could see the behavior or help you to create the debug environment.

[AndreaBorgia-Abo]

A Teams session would be a good idea, let me discusss this internally first then I'll get back to you. @fidley see Linkedin chat for the planning

[fidley]

@lukas-mb we found the issue with @AndreaBorgia-Abo , he was using sorting of the components without opening the Preferences for it (so initial status). When doing so, there was no collection for the statements not matching the initial prefixes. fix will be to add empty prefix here and here

[fidley]

Will publish it in the evening

[fidley]

deployed

[lukas-mb]

oh, that explains why it worked for us. Thank you for fixing!