windows 人们如何看待 Gupta Team Developer？

What do people think of Gupta Team Developer?

提问by Stewart

Has anybody any experience in using Gupta (formerly Centura) Team Developer?

有没有人有使用 Gupta（以前称为 Centura）Team Developer 的经验？

If so, what do you think of it in terms of its capability to support the development of mature, scalable, maintainable applications?

如果是这样，您如何看待它支持成熟、可扩展、可维护的应用程序开发的能力？

Thanks

谢谢

回答by Stephan Keller

I have been using the CTD since version 1.1. Currently I'm still using 2.1 PTF4, mainly for doing rich client CRUDs under windows 98-Vista against Centura SQLBase, MS Sql Server or MS Access. I have not upgraded from 2.1 to the newer versions, so I can only talk about the relatively old 2.1 from 2001.(§)

我从 1.1 版开始使用 CTD。目前我仍在使用 2.1 PTF4，主要用于在 windows 98-Vista 下针对 Centura SQLBase、MS Sql Server 或 MS Access 执行富客户端 CRUD。我没有从 2.1 升级到较新的版本，所以我只能谈谈 2001 年相对较旧的 2.1。(§)

Our applications typically have about 150 form windows, make heavy use of classes (still called "user defined variables" in 2.1) and integrate MS Office. We have no stability issues or memory leaks. The development environment is a bit long in the tooth, though: no intellisense, no smart debugging and practically unusable without a mouse. This may have changed with newer versions.

我们的应用程序通常有大约 150 个窗体窗口，大量使用类（在 2.1 中仍称为“用户定义的变量”）并集成了 MS Office。我们没有稳定性问题或内存泄漏。然而，开发环境有点长：没有智能感知，没有智能调试，没有鼠标几乎无法使用。这可能会随着更新的版本而改变。

There is nothing in the nature of CTD that forces you to write un-maintainable code. Using classes and file-includes you can have a good degree of reusability in your code ifyou designed your code to be reusable, that is. A problem for maintainability may be that CTDs variables and classes do not have access modifiers like "private" or "protected". Also: no interfaces or abstract classes. On the other hand: multiple inheritance.

CTD 的本质没有强迫您编写不可维护的代码。如果您将代码设计为可重用，那么使用类和文件包含您可以在代码中获得良好的可重用性。可维护性问题可能是 CTD 变量和类没有访问修饰符，如“私有”或“受保护”。另外：没有接口或抽象类。另一方面：多重继承。

The "outline structure" of the code takes some getting used to, but I even sometimes miss the outline structure when I get lost in a sprawling C#-file with variable declarations and event handlers all over the place...

代码的“大纲结构”需要一些时间来适应，但是当我迷失在到处都是变量声明和事件处理程序的庞大 C# 文件中时，我什至有时会错过大纲结构......

The controls for 2.1 where pretty complete but we still had to manually integrate "modern" things like toolbars, datepickers or tab-controls. OTOH it even has a numerical input field out of the box. One of the Unify-Newsletters stated that they added a lot of eye-candy, to let the apps look more up-to-date. The mtable-Extensions for table windows where very helpfull, available here: MTable by MICSTO. Integrating 3rd-party-DLLs (e.g. for integrating a smartcard-reader) is not really fun, especially when they use structs. Oh: and the "Centura Report Builder" is a royal pain in the derierre.

2.1 的控件相当完整，但我们仍然必须手动集成“现代”的东西，如工具栏、日期选择器或选项卡控件。OTOH 它甚至有一个开箱即用的数字输入字段。其中一份 Unify-Newsletters 表示，他们添加了很多引人注目的内容，以使应用程序看起来更及时。表格窗口的 mtable-Extensions 非常有用，可在此处获得：MICSTO 的 MTable。集成第 3 方 DLL（例如用于集成智能卡读取器）并不是很有趣，尤其是当它们使用结构体时。哦：而“Centura Report Builder”是一种皇家痛苦。

A big pro is the SDK that shipps with the CTD: this makes it very easy to integrate self written tools into the development environment, e.g. for code generation.

一个很大的优点是随 CTD 提供的 SDK：这使得将自编工具集成到开发环境中变得非常容易，例如用于代码生成。

Bottom line: We used and still use CTD for scalable and maintainable apps. The learning curve can be a bit steep because of the unusual outline structure and can lead the unwary towards writing "ugly" code: e.g. lots of static functions, lots of code in the "Message Actions" and problems with variable scoping. I think your success with CTD will depend on the nature of the application you want to write: for a rich client CRUD you might almost certainly be better off than with .net, for a web app I honestly don't know.

底线：我们使用并仍在使用 CTD 来开发可扩展和可维护的应用程序。由于不寻常的大纲结构，学习曲线可能有点陡峭，并且可能导致粗心大意的人编写“丑陋”的代码：例如大量静态函数、“消息操作”中的大量代码以及变量作用域的问题。我认为您使用 CTD 的成功将取决于您要编写的应用程序的性质：对于富客户端 CRUD，您几乎肯定会比使用 .net 更好，而对于 Web 应用程序，我真的不知道。

Keep in mind that all this relates to the 8 year old 2.1 version of CTD. Things may be radically different now. If you can, get an evaluation version.

请记住，所有这些都与 8 岁的 CTD 2.1 版本有关。现在情况可能完全不同。如果可以，请获取评估版。

Edit: Aside from the pros and cons of the language alone, you might want to consider that CTD is a niche. There are not many free tools and I have yet to find a vibrant community (there was a newsgroup, but the server went down after the merger - maybe its still around somwhere). So, googling up help on specific Problems may no be easy.

编辑：除了语言本身的优缺点外，您可能还想考虑 CTD 是一个利基市场。没有多少免费工具，我还没有找到一个充满活力的社区（有一个新闻组，但合并后服务器宕机了——也许它还在某个地方）。因此，在特定问题上搜索帮助可能并不容易。

(§) I did not continue the upgrade path from 2.1 to 5.1 because after the merge with Unify they wanted to make patches available only for subscribers to their support scheme (called GLS). Since I was not going to pay for bugfixes I deceided to continue using 2.1 for our legacy apps and switch to .net for new apps. I think they revised this later on.

(§) 我没有继续从 2.1 到 5.1 的升级路径，因为在与 Unify 合并后，他们希望仅向其支持计划（称为 GLS）的订阅者提供补丁。由于我不打算为错误修复付费，我决定继续为我们的旧应用程序使用 2.1，并为新应用程序切换到 .net。我想他们后来修改了这个。

回答by twilight

I have been working with Team Developer (formerly Centura Builder, SQL Windows, etc.) for 9 years. IMO things have not changed too much from the version 2.1 which Stephan Keller described in his comprehensive answer.

我已经与 Team Developer（以前的 Centura Builder、SQL Windows 等）一起工作了 9 年。IMO 的事情与 Stephan Keller 在他的综合回答中描述的 2.1 版相比没有太大变化。

The company I am working for is currently using TD version 5.1 and considering upgrade to TD 5.2 next year. We are developing a business software product, run against Oracle database. The application has more than 500 form windows and several hundred reports.

我工作的公司目前正在使用TD 5.1版本，并考虑明年升级到TD 5.2。我们正在开发一个商业软件产品，运行在 Oracle 数据库上。该应用程序有 500 多个表单窗口和数百个报告。

I think Team Developer scales well to both simple small applications, and larger enterprise application suites with big RDBMS and hundreds of users.

我认为 Team Developer 可以很好地扩展到简单的小型应用程序和具有大型 RDBMS 和数百个用户的大型企业应用程序套件。

The code outline makes the IDE easy to approach and I think the learning curve will not be that steep. The code editing is possible even without mouse, since there is a number of handy keyboard shortcuts. Of course the window designer needs mouse. There is also a built-in Active Coding Assistant in the newer releases.

代码大纲使 IDE 易于使用，我认为学习曲线不会那么陡峭。即使没有鼠标也可以进行代码编辑，因为有许多方便的键盘快捷键。当然，窗口设计者需要鼠标。新版本中还有一个内置的 Active Coding Assistant。

The newest releases (5.1 and 5.2) offer some new GUI controls, such as a date/time picker, a grid window (enhancement to the widely used table window) and Rich Text editor. There is also a new tab control. Menus can be shown ribbon-like, though this is not a "real" ribbon bar. Sample screenshots can be found on the Unify web site.

最新版本（5.1 和 5.2）提供了一些新的 GUI 控件，例如日期/时间选择器、网格窗口（对广泛使用的表格窗口的增强）和富文本编辑器。还有一个新的选项卡控件。菜单可以像功能区一样显示，尽管这不是“真正的”功能区栏。可以在 Unify 网站上找到示例屏幕截图。

Also new GUI themes were introduced in the 5.x versions of TD, to provide a more modern look and feel for the applications.

TD 的 5.x 版本中还引入了新的 GUI 主题，为应用程序提供更现代的外观和感觉。

There have been a number of stability issues, performance problems and problems with screen painting etc. with the 5.x versions of TD. The older 3.x and 4.x are known of very robust quality, having only a very limited number, if any, stability or other issues. These issues are discussed actively on the Unify Support Forum. Many of these issues are related to database routers (Oracle, MS SQL Server) or Windows API calls. The basic functionality of TD is usually working quite fine.

TD 的 5.x 版本存在许多稳定性问题、性能问题和屏幕绘制问题等。众所周知，较旧的 3.x 和 4.x 质量非常强大，只有非常有限的数量（如果有的话）稳定性或其他问题。这些问题在统一支持论坛上得到了积极的讨论。其中许多问题与数据库路由器（Oracle、MS SQL Server）或 Windows API 调用有关。TD 的基本功能通常运行良好。

Also help on specific problems and questions can be reached on the Support Forum. The developer community is maybe small, but quite active.

还可以在支持论坛上获得有关特定问题的帮助和问题。开发者社区可能很小，但非常活跃。

回答by C. Stoll

My Company uses Team Developer for years successfully (most of our Applications are written in 2.0, with some in 5.2 as Web-Applications) and there are plans to change our development to version 6.0.

我的公司多年来一直成功地使用 Team Developer（我们的大部分应用程序都是用 2.0 编写的，有些是 5.2 版本的 Web 应用程序），并且计划将我们的开发更改为 6.0 版。

Coming from a C++ background I first had to find the way into the language (I still miss some features like encapsulation, well-structured error handling¹or scoping of variables²)

来自 C++ 背景，我首先必须找到进入语言的方法（我仍然想念一些功能，如封装、结构良好的错误处理¹或变量范围²）

But after all, I learned to live with the limitation of the language and with some discipline our applications are relatively easy to maintain. (as a note: We have a set of base applications working together and use the same codebase with some customer-related variations to build individual versions for every customer - bugfixes appear at the common codebase (and is used afterwards for any other project), special modifications at the lokal project files). You just need to set up some basic guidelines for your projects and keep with them as the compiler wouldn't enforce them.

但毕竟，我学会了忍受语言的限制，并且通过一些纪律，我们的应用程序相对容易维护。（注意：我们有一组共同工作的基本应用程序，并使用相同的代码库和一些与客户相关的变体来为每个客户构建单独的版本 - 错误修复出现在公共代码库中（随后用于任何其他项目），本地项目文件中的特殊修改）。你只需要为你的项目设置一些基本的指导方针并保持它们，因为编译器不会强制执行它们。

---

---

¹You could catch a sql error only at the point it occurs or globally for the whole program.

¹您只能在它发生时或在整个程序的全局范围内捕获 sql 错误。

²I still sometimes get cases where a mis-spelled variable compiles for something in a completely independent window - or compiler errors for semi-referenced handles sharing the same name but different data types

²我有时仍然会遇到拼写错误的变量在完全独立的窗口中编译某些内容的情况 - 或者共享相同名称但不同数据类型的半引用句柄的编译器错误

回答by Altex Lansing

We used TD for several large apps but due to the lack of resources, the obsolete SAL language and aged runtime we have migrated millions of lines of SAL code and several thousand forms to C# and Visual Studio 2010 using ice tea group gupta/unify migration tool.

我们将 TD 用于几个大型应用程序，但由于缺乏资源、过时的 SAL 语言和陈旧的运行时，我们使用冰茶组 gupta/unify 迁移工具将数百万行 SAL 代码和数千个表单迁移到 C# 和 Visual Studio 2010 .

We were skeptical at first. But now we have brand new apps, fully integrated with our other .NET assetts with a small fraction of the time needed for a rewrite. And we didn't have to try to understand what all that all code was doing. :) the conversion was nearly perfect!

起初我们持怀疑态度。但是现在我们有了全新的应用程序，与我们的其他 .NET 资产完全集成，重写所需的时间很少。而且我们不必试图理解所有代码在做什么。:) 转换几乎是完美的！

Forgot to mention that we automatically converted over 1200 report builder reports to crystal reports .NET saving probably a century of boring work.

忘了说，我们自动将 1200 多个报表生成器报表转换为水晶报表 .NET，可能节省了一个世纪的枯燥工作。