Version 1.3 breaks $(Include=InitLink.qvs) functionality

[celindho]

Hi,

I just tested updating an existing framework to version 1.3 and I immediately noted that all reloads started failing. It appears that the new way that the framework uses to find the BasePath does not mix well with having an InitLink.qvs file in every folder of the 1.Application tree.

Is it a deliberate action to not support the CreateInitLink.bat => $(Include=InitLink.qvs) way of initialising the framework? I.e. should I migrate all my applications to use

$(Include=..\..\..\..\3.include\1.basevariable\1.init.qvs);

$(Include=..\..\..\3.include\1.basevariable\1.init.qvs);

$(Include=..\..\3.include\1.basevariable\1.init.qvs);

$(Include=..\3.include\1.basevariable\1.init.qvs);

instead or will this problem be fixed in the next release?

BR,

-Christian

[Magnus_Berg · Accepted solution]

Hi Christian,

I have checked in the code and the newer way of identifying a container demand that there is a InitLink.qvs (hidden) in the Container root. This is a more flexible solution than before But this means (sorry to say) that CreateInitLink does not work correct any more and will be removed. Below is a dynamic Init script that will be a substitute for InitLinks in the future.

Cheers

SET vG.BasePath=;
SET vL.Path_tmp = ;

     for vL.x =1 to 10-1

          LET vL.Path='..\'&'$(vL.Path_tmp)';

          LET vL.Path_tmp='$(vL.Path)'; $(Include=$(vL.Path)InitLink.qvs);

     exit for when not '$(vG.BasePath)'= '' next

SET vL.Path = ;

SET vL.Path_tmp = ;

$(Include=$(vG.SubPath)\4.GenericContainerLoader.qvs);

This script will automatically try to find 1.init.qvs by searching for InitLink.qvs it’s a hidden file stored in every container root.

[celindho]

Hi Magnus,

Thanks for the quick reply! Any guesses on when the next minor version will be released?

-Chistian

[Magnus_Berg]

Sorry..