Have been working around this problem for quite awhile, but would be very interested to hear if anyone else has ever seen the same or similar.
Whenever I do a full generate/build of one solution, the embed code for a set of methods is not get generated into the source module. This occurs ONLY for methods added to the WindowManager class and ONLY for embed code added via the embedditor (tree or source). Method declarations are all generated correctly. The result is a set of methods having only the CODE statement.
The problem occurs in 4 ABC procedures, each within a different app. The only way I have found to force full generation of the code is to re-open the code in the embedditor for one method, make a change in a bogus first line comment, and regenerate code for that app. This work around process, MUST be done at least twice. Re-opening the code in the embedditor a single time has never been sufficient.
I have also tried exporting each app or even just the 4 procedures to TXA and reimporting without results.
Any and all ideas are welcome.
Hello,
Yes, I’ve experience this issue in a couple of projects for one of my clients.
It appears the default instance for the window manager gets confused with the instance of a template in the procedures.
What it appears to be is if the first template in the procedure supports “additional methods” like the procedure template itself, the instance numbers between the procedure itself and template gets crossed up.
I emailed back and forth with SoftVelocity a fair amount with examples. We did not come up with a reason for what was happening.
One solution is to export to TXA and then make sure the first template [ADDITION] for the procedure is a simple template that does not support the OOP derived methods support.
For both of my procedures demonstrating the problem, I moved one of the other [ADDITION] extensions to be the first [ADDITION] in the procedure. I chose a simple template that did not implement a class with the ABC OOP prompts.
I then changed the instance of the template that was cross linked with the procedure (I had tried just this step earlier).
I imported the APPs from TXA. I had to fix up orphaned embeds because of the instance change.
After doing this I have generated the procedures many times w/o issue. I exported and re-import the APPs and generated again (normally this triggered the problem) and everything is working.
This does not re-solve how the issue happens in the first place.
It seems like which template is the first one for the procedure has a significant impact.
This is definitely different than how it worked in the past.
Even though I came up with this workaround, I have not used it subsequently. It’s just too much work.
Instead, when the problem occurs, I declare a local class LP in embed code and move the derived methods from the Window Manager to this new local class. I put the methods in the Local Procedure embed point.
Not the best solution but has saved me way more time than banging my head against the wall trying to force the window manager derived methods to generate properly.
HTH,
Rick
Rick,
Thank you very much. I will spend some time looking at both solutions. I was thinking that some manual changes in a procedure TXA might do the trick. I wish I had noted the Clarion version where this first appeared, as that might give SV a clue. Certainly I had never heard of or experienced the problem in all the years since the ABC templates were introduced.
One additional symptom that really leaves me scratching my head is that after the first re-generation of an app, the compiler will often NOT report errors for methods requiring a returned value. Instead, to confirm full generation of the embed code, one must open the source module and look to see that there is indeed something after the CODE statement.