|
|
||
|
|
||
Obsydian 3.x | To be Announced | Group Model implementation in RDBMS (Moved from R3.0) |
Considerations |
* Note that this is the availability date for N. America. Please consult the local Synon representative in your area for specific availability dates.
Please send Ramon Chen, Director, Products any questions or comments you may have regarding the information on these highlights and considerations.
Please note that these are very early highlights and are subject to change.
Check this page for updates.
FEATURE | OVERVIEW |
Storage of Group Model in RDBMS |
In the R3.x timeframe all Group
models will be stored in an RDBMS. SQL Server 6.5 will be the initial database supported. Support for an additional database will follow in subsequent releases. The schedule and choice of the next database is being evaluated and more information will be available shortly. |
Support for ActiveX/OCX controls | Obsydian's R3.0 ActiveX/OCX support will be
equivalent to today's VBX support. VBX support will be retained for 16-bit applications but with some caveats and SUPPORT FOR VBX controls in 32-bit apps will be removed. (see considerations section) Developers will be able to use controls on panels, view them in the panel editor, and set standard properties. In addition, through API calls in the action diagram editor, developers will be able to invoke methods and set properties at runtime. An additional feature will be the ActiveX Property sheet, which will show the options available for a property as well as the displaying the documentation string for each property. |
User Interface improvements | There are a number of tool interface
improvements, driven by a comprehensive UI and Usability strategy review earlier this
year. Tool
Diagrammer
Action Diagrammer
Panel Designer
|
New Triples Modified Triples |
There are a small number of triple changes planned
for R3.0, mostly to support JAVA generation. They include:
|
ActiveX/OCX controls
At present Synon anticipates that
z-ordering is improved with ActiveX, although Synon is in the early stages of testing.
Also, it's still the case that ActiveX controls cannot be placed into the Control region
and hence cannot be manipulated by 'state change' instructions.
Changes in VBX Support
Currently under 2.51 VBX controls can be
designed in the Obsydian 16-bit tool for deployment in both 16-bit and 32-bit
applications.
IMPORTANT OBSYDIAN 3.0 HEADS UP BULLETIN FOR VBX USERS WITH 32-Bit apps
Obsydian 2.5 introduced the ability to create 32-bit clients. To allow you to take advantage of graphical controls, Obsydian 2.5 provided a special capability to embed VBXs (16-bit graphical controls) in those 32-bit clients.
The upcoming Obsydian 3.0 will allow you to take advantage of new ActiveX controls (32-bit graphical controls) as well as retaining support for VBX support in 16-bit clients.
Given this, the support for VBXs in 32-bit clients will be discontinued in R3.0, you will have to replace them with ActiveX controls.
What this means to you if you currently have VBXs embedded in 32-bit clients:
* If you are using existing VBX APIs in Action Diagrams they will continue to work if you can find ActiveXs which have a) the same control name and b) the same property names as the existing VBX.
* Otherwise you will have to revisit those VBX APIs in those action diagrams and use new method APIs (provided in R3.0) to access the new ActiveX controls.
Note that our current research and testing indicates that many of the ActiveX control versions of current VBX's do have different property names so the second scenario appears to be the more likely of the two.
In addition, because R3.0 Obsydian will be a 32-bit tool, the 16-bit panel design mode will not be able to visually display a VBX (which is a 16-bit control). Generated 16-bit applications will still support VBX's but the only difference is that the panel designer will be unable to provide WYSIWYG support or support to query VBX properties. You will still be able to manually add and manipulate VBX controls through the documented VBX APIs.
Related Changes to NL and Variant Dependent Triple Behavior
Existing triples will be 'updated' as part of the R3.0 conversion/upgrade.
The implementation of Variant and National language-sensitive triples has been modified to enable triples entered in a particular Variant/NT to override a generalized triple in Base. In R3.0, a triple entered in a particular Variant/Language is created in that configuration, then overrides the triple in Base.
This change of behavior should not adversely affect existing models, since the original behavior usually prevented the addition of a specific Variant/Language triple if one already existed in Base, due to cardinality restrictions.
Developers who have overcome the original implementation by entering the Variant/Language triple first, changing the configuration to Base, entering the Base triple and restoring the Variant/Language configuration will need to review their models after upgrade/conversion. (in this case both triples would be seen in the Model Editor despite infringing cardinality rules, the resolution of precedence being applied via relative position, with the later overriding the earlier).
The behavior will no longer be supported and will, instead, reflect the new Base-Variant/Language model.
If you were a Club Lava member you would have heard the news first! Don't delay, join Club Lava today!
Tuesday, July 15, 1997
LavaLights: Volume 1 Issue 5
In this fifth issue of LavaLights, Club Lava member's exclusive news and views e-mail, I am excited to report some breaking news which highlights the power of your input and Synon's ability to be instantly responsive to our customers.
I hope you enjoy this issue of
LavaLights, please reply to this e-mail with your full name, company name and membership
number with any comments or questions. Thank you for being a Club Lava member!
Regards
Ramon Chen
Product Manager, Obsydian
Synon Inc.
In LavaLights Vol 1 Issue 2 we posed the question about Microsoft's SQL Server and the storage of the group model in R3.0 in this RDBMS. We asked how many would wait for a subsequent RDBMS to be supported. The response from Club Lava members together with surveys and focus groups indicated to us that many of you would wait.
Given the feedback we received from you, Synon has determined that it would be best to move the group model RDBMS storage functionality to a release after R3.0. This will allow you to benefit from the wealth of functionality available in R3.0 without requiring an RDBMS.
By deferring the group model RDBMS storage functionality to a subsequent release and unifying the implementation with the scheduled local model RDBMS storage implementation, we will give you more time to plan for this eventual move. We also believe it will be easier for everyone concerned if both group and local models are addressed in the same release, rather than spreading the configuration and upgrade over two releases.
This will also afford us with the opportunity to extend our testing coverage to more ODBC databases in addition to SQL Server when RDBMS storage of group and local models is released.
This change is as a direct result of your feedback. It highlights the importance of Club Lava Members and once again shows Synon's ability to move quickly to adapt to changing market requirements and to be exceptionally responsive to the needs of our customers.
I hope you are encouraged by what has taken place, please send me e-mail at rwc@synon.com if you have any comments or questions.
©1995-98 Synon Corporation. All rights
reserved. |