TMS VCL UI Pack 10.0.8.0 to 10.1.1.0 Link Issue

Hello,

After upgrading from TMS VCL UI Pack 10.0.8.0 to 10.1.1.0, I'm experiencing a linking issue with many of my projects (examples below).  Reverting to 10.0.8.0 resolved the linking error.  I also found that manually adding #pragma link "wininet.lib" to my project will resolve the problem.

Is there an ETA to an updated version of the components that do not require this manual edit to resolve the linkage issue?

Thanks,
Royce Arnold


[ilink32 Error] Error: Unresolved external 'InternetOpenW' referenced from D:\LIBRARY\RAD STUDIO\TMS VCL UI PACK\DELPHI102TOKYO\WIN32\RELEASE\TMSVCLUIPACKPKGDXE11.LIB|AdvUtils
[ilink32 Error] Error: Unresolved external 'InternetOpenUrlW' referenced from D:\LIBRARY\RAD STUDIO\TMS VCL UI PACK\DELPHI102TOKYO\WIN32\RELEASE\TMSVCLUIPACKPKGDXE11.LIB|AdvUtils
[ilink32 Error] Error: Unresolved external 'HttpQueryInfoW' referenced from D:\LIBRARY\RAD STUDIO\TMS VCL UI PACK\DELPHI102TOKYO\WIN32\RELEASE\TMSVCLUIPACKPKGDXE11.LIB|AdvUtils
[ilink32 Error] Error: Unresolved external 'InternetReadFile' referenced from D:\LIBRARY\RAD STUDIO\TMS VCL UI PACK\DELPHI102TOKYO\WIN32\RELEASE\TMSVCLUIPACKPKGDXE11.LIB|AdvUtils
[ilink32 Error] Error: Unresolved external 'InternetCloseHandle' referenced from D:\LIBRARY\RAD STUDIO\TMS VCL UI PACK\DELPHI102TOKYO\WIN32\RELEASE\TMSVCLUIPACKPKGDXE11.LIB|AdvUtils

Is there an old version of AdvUtils.hpp around on your system?
Please search & delete all old version files.
The file AdvUtils.hpp should have the lines:

#pragma link "wininet.lib"
#pragma link "urlmon.lib"

and this should take care of this.
Bruno,
Thanks for the info.

I find only 2 copies of AdvUtils.hpp (one for x32 and one for x64).  My application are x32 and I checked the AdvUtils.hpp for the presence of the 2 #pragma lines listed.  They are present in both 10.0.8.0 and 10.1.1.0 version of the x32 AdvUtils.hpp (note I did not check the x64 version).

However, the project will not link under 10.1.1.0 and reports the linking errors as noted in my original message.  Reverting to 10.0.8.0 resolves the linkage issue.  Manually including the #pragma lines does as well.

Repeatable behavior on both on my systems.  Project links under 10.0.8.0 and does not under 10.1.1.0  no other changes.  I do a clean and build between version switches.  Maybe one of the components is no longer including AdvUtils.hpp?  Most of my components are TMS DB aware VCL controls.


Is AdvUtils.hpp referenced in your project?
If not, what components are being used? How exactly can this be reproduced?


AdvUtils.hpp is not directly referenced by my project.

The main form is currently using
    TAdvPanel, TButton, TAdvGroupBox, TDBAdvEdit.

I'll have to generate a stripped down project that has the same errors.  The current project has too many client proprietary details to send as is.




Bruno,

The problem appears to with the TAdvPanel component.
Try this:
1.  New C++ VCL Form Application.
2.  Setup for Static Linking (Link with Dynamic RTL = false, Link with runtime packages = false).
3.  Add TAdvPanel
4.  Build it.

Linking errors.

Also, is there a reason that the caption is now visible by default?

Also, the forum seems to be timing out for submissions.  FYI.

We have implemented a solution for this that will be included in the next scheduled update.

Thanks.  I'll revert back to 1.0.8.0 until it is released.  

Problem persist in 10.1.2.0.

Did you retest steps:


The problem appears to with the TAdvPanel component.
Try this:
1.  New C++ VCL Form Application.
2.  Setup for Static Linking (Link with Dynamic RTL = false, Link with runtime packages = false).
3.  Add TAdvPanel
4.  Build it.

I can no longer reproduce a problem with these steps.

Hmm...

It works for new projects.  But any existing project exhibits the issue.  Even the simple project that I constructed using those steps does not link.

It looks like you had the #pragma AdvUtils added when the component is added to the form.

I have a ~100 existing application that would require this to be done manually. I use TAdvPanel everywhere...  Is there an alternate solution to return the behavior to <= 10.0.8.0.



It's been a long time since I did any component development...
Is there anyway for you to force the inclusion of  "#include <AdvUtils.hpp>"  to advpanel.hpp file?  I know that file is automatically generated, but adding it manually seems to resolve the linkage issue.

We did the change that when you add a new TAdvPanel on the form, the IDE should add the unit (or HPP for C++ users) AdvUtils

Bruno,

That solution is not going to resolve my existing projects link issues.  I really need a solution to that.  Simply too many existing projects to maintain using TAdvPanel to manually have to edit each one to solve the problem.


Royce

It is a new requirement in TAdvPanel and we did the necessary modifications to make this work when dropping a new TAdvPanel on the form. The moment a component is added on the form is the only moment when it can have an effect on the form file.

If you do not want to change every form file and add AdvUtils.hpp, you could add in your main application CPP file:

#pragma link "wininet.lib" and this should also solve it application wide with one extra line of code.
Bruno,

Respectfully, that solution is not really workable for me.  As I have previously stated, I have ~100 projects (not forms) that would require this source modification in order to compile.

The change in behavior seems like a SERIOUS regression from my perspective.  Looking at the change log, I see no comments that indicate a change of this magnitude was being implemented or that the changes to existing projects would be required.  The only change I see mention is the Office 2019 styling and I do not see where that would involve internet component on TAdvPanel.

So, please consider finding a solution that does not require edits to my numerous existing projects.

Sincerely,
Royce



This is NOT a regression, this is because new functionality was ADDED that images from HTTP(s) resources can also be accessed.

Regardless, we will investigate if we can find an alternative solution.

Bruno,

Thanks for investigating further.  I can see that release 10.1.3.0 implements a different solution that does not cause me to edit every existing project.  THANK YOU.

I meant no offense when I labeled this issue as a regression.  I guess it is a matter of perspective.  From mine, a upgrade with no mentioned functionality change in the version history broke my existing code bases.  So from my perspective, it was a textbook definition of a regression.  I understand you had a different view on it not being one.  But I hope you can understand why I would feel like it was.