|
|
本帖最后由 wdyjz 于 2010-12-7 15:14 编辑
1.1.3报表工具包是为LV8.6开发的，开始使用了面向对象的class技术，自此，噩梦开始。
生成的exe文件夹内多了很多的报表的支持的VI。
而且，build exe时，提示
LabVIEW prevented a file name collision during the build. Duplicate file names cannot be copied to the same destination. You can rename files as part of the build process to avoid name conflicts.
The following files were moved to a unique location:
NI官方网站上关于这个话题的讨论，简直是....，自己看
http://forums.ni.com/t5/LabVIEW/Build-name-conflicts-NI-Report-Generation-Toolkit/td-p/803239/page/3
很难解决，LV2009下的报表工具包也不例外吧
看NI开发工程师的解释：
Hey everybody,
Sorry I'm a couple of months late to the RGT bashing party.  I had not seen this thread until today. I took over ownership of the Report Generation Toolkit late in the release cycle for version 1.1 back in early 2004. I was the primary developer for versions 1.1.1 and 1.1.2. I will also be the primary developer for the next release. I was not the developer for the 1.1.3 release that accompanied LabVIEW 8.6, but I was very much involved in the early design and brainstorming. I'd like to explain why we made some of the choices that we did.
As you may know, the LabVIEW 8.6 release centered around the Platform DVD, which was NI's way of unifying LabVIEW, its modules, and its toolkits, all under one installer. The advent of the Platform DVD meant that the 8.6 release, and all future releases, would include updates for each and every module and toolkit. It also meant that all products that fall under the Platform DVD umbrella would now be licensed, which gave LabVIEW users the benefit of being able to install and run any module or toolkit with a 30-day evaluation period. So at this point, understand that it was a 100% requirement that the Report Generation Toolkit become licensed under 8.6.
Now, a peculiar thing about the Report Generation Toolkit prior to 1.1.3...it was the only LabVIEW toolkit that actually *replaced* files on disk when you installed it. Specifically, it replaced vi.lib\utility\nireport.llb, several LLBs in the vi.lib\printing folder, several .mnu files in the menus folder, a .chm or two in the help folder, etc. All of these replaced files had added functionality to support generating Word and Excel reports. If you uninstalled the toolkit, we would replace the files with the original core LabVIEW files.
Unfortunately, this design was completely incompatible with the way licensing works. In order for VIs and palettes to check license status, the VIs and .mnu files in question must be part of a licensed library. There was no way we could continue to overwrite files on disk (and remove/replace them on an uninstall). That would require us overwriting the files when you install the toolkit, but if you're doing an eval, and you didn't activate after 30 days, we'd have to somehow revert back to the old files...but if you then activated at a later date, we'd have to replace the files again. There's nothing in our licensing scheme that even remotely supports this behavior. And since RGT was the only toolkit that fell into this category, we decided the best idea was a redesign of the toolkit, and the Report Generation API in LabVIEW, to support a plug-in architecture where we could install new files alongside the core Report Gen VIs to add the Word and Excel functionality, without changing anything in the core VIs (which support Standard and HTML reports).
So looking at an API that was refnum-based and needed the possible dynamic creation of report types (i.e. sometimes you may have the Word and Excel stuff installed, but sometimes not), we decided to go with LabVIEW Classes. Obviously there are pros and cons to this approach...the biggest con, as we have seen in this discussion thread, was the creation of folders of support VIs next to the EXE when building an executable. I'll be honest, we did consider this scenario while brainstorming the redesign, but since the issue of building same-named VIs into an EXE already existed prior to the toolkit (since it can happen with standard .lvlibs), and since we knew we had no choice but to go ahead with the redesign, we stuck with the LV Classes approach.
All this being said, we did not anticipate it being as big a problem as all of you (and even some internal LabVIEW users at NI) have indicated. And for my part in the decision-making, I apologize for that. I will reiterate a previous point made in this thread, which is that we are actively investigating ways to solve the "extra files next to the EXE" problem in a future LabVIEW version, not just for RGT, but for any app that has same-named VIs.
So now that I own the toolkit again, I'm happy to take suggestions on things y'all would like to see "fixed" in the next release. And let's assume that the architecture will continue to be class-based, and that we are already trying to solve the extra files with the EXE issue. What other major problems have y'all had with this most recent release of the toolkit that you would like to see addressed?
-D
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman
|
|
狗仔卡
发表于 2010-12-6 21:24:55
提升卡
沉默卡
喧嚣卡
变色卡
抢沙发
显身卡
楼主
发表于 2010-12-10 14:24:21
