Q: After an entire night, Olivier and I finally found out the reason why we did not generate the full migrated code yesterday. Or, should I say, … almost. To go straight, the trouble is (mainly) this line in the WpfAuthorProject routine :
public static void WPFAuthorProject(int projectRoot,int commands)
{
int iRoot;
int objType;
tInfoFile compInfo;
int textRoot;
int oldFlags;
Runtime.ProjectInfo(projectRoot);
WPFRuntimeInformation();
textRoot = Write.OpenStream();
Runtime.ProjectAssembly(projectRoot);
AuthorProjectAssembly(projectRoot,0);
Runtime.AuthorLibrary(projectRoot);
Write.CloseStream();
compInfo = new tInfoFile(projectRoot,true);
compInfo.tranBase = textRoot;
oldFlags = compInfo.SetContextFlags();
Project.prjVbname = compInfo.vbName;
iRoot = Store.GetFirst(projectRoot);
while(iRoot != 0)
{
objType = Store.GetObjectType(iRoot);
if(objType == ObjectType.FormFile || objType == ObjectType.ModuleFile || objType == ObjectType.ClassFile)
{
Project.childRoot = iRoot;
compInfo = new tInfoFile(iRoot);
if(!compInfo.DeadCode && !compInfo.Foreign)
{
Write.OpenStream();
Project.CurrentClass = compInfo.vbName;
if(objType == ObjectType.FormFile)
{
WPFAuthorControls(iRoot,0);
}
Runtime.TargetCode(iRoot,projectRoot,true);
textRoot = Write.CloseStream();
compInfo = new tInfoFile(iRoot,true) { tranBase = textRoot }; // Not Used? <------- they questioned this line; also changed to use extended constructor call syntax rather than two assignments.
}
}
iRoot = Store.GetNext(iRoot);
}
Project.flags = oldFlags;
Runtime.FinishTranslation(null,commands);
}
As the 'comInfo' variable was not used it has been commented out. And it has been done among a huge refactoring change set.
But, although this variable was not used, the tInfoFile constructor has obviously a very important side effect. If it's not called here, the code does not generate the solution content anymore (even if it's called before).
This behavior is not really expectable (despite the class name, it's just constructor, no comment in the code to warn about it and we were not able to find any documentation explaining what it really does). But more than that, even once we discovered that at line 2740 of a 2750 lines code file (bad luck, after having analyzed line by line all the previous) we were not able to get a complete migration on our refactored code. We finally realized that the trouble is spread out along several instructions like this one and the effect of their combination is even more opaque and unpredictable (with some of them you get only a "half" migration – it means an incomplete bundle).
We should discuss it again because it's a real concern for us regarding the maintainability of this code.
Regards.
A: A critical step in the logic is assigning compinfo.tranBase = textRoot.
tranBase is a property used to to store the address of the text storage containing the translated code for the given component.
setting tranBase=textRoot saves that location so that it may be accessed later for example for Post-Edits and ultimately writing it to disk as part of the bundle file. Comment out that line of code prevents the tool from finding the text buffers containing the authored code.
That is why the bundle was incomplete.
Keep this in mind: gmBasic uses a proprietary information management system. This system is used to setup and access a large hierarchical model of the entire system VB6 code, COM APIs, the tool's metalanguage, and also numerous text storage areas for various input and output files. We call all of this information "The Model". The API is service-oriented and it makes heavy use a static classes to access the model which is a resource shared by all services. It is better to think of assignment to model elements as service requests telling the information management system to get or set something for you.