You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
(6) |
Apr
(13) |
May
(4) |
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
(3) |
Nov
(16) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(11) |
Feb
(10) |
Mar
(7) |
Apr
(11) |
May
|
Jun
(1) |
Jul
(7) |
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2009 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: SourceForge.net <no...@so...> - 2007-04-27 02:20:19
|
Bugs item #1689384, was opened at 2007-03-27 10:42 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1689384&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Tyler (tynman) Assigned to: Nobody/Anonymous (nobody) Summary: "Reverse Role Order" does not refresh Initial Comment: In the context window of a fact type under Orientation, clicking "Reverse Role Order" does change the order of the roles, but it does not redraw the role/entity type connection lines. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-04-26 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Matthew Curland (mcurland) Date: 2007-04-12 10:46 Message: Logged In: YES user_id=1452263 Originator: NO Fixed in changeset 1013. Swap role order (available on the role) always worked, reverse only worked after a display order had been explicitly set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1689384&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-04-24 02:49:26
|
Bugs item #1705888, was opened at 2007-04-23 23:36 Message generated for change (Comment added) made by cjheath You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1705888&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Clifford Heath (cjheath) Assigned to: Nobody/Anonymous (nobody) Summary: Serious correctness issues in generated SQL Initial Comment: I'm using the generated SQL Server code from the Orienteering model (this version is revised from the one posted in a previous bug report) and there are numerous things that either don't run (incorrect SQL) or are just logical errors. Some of the things I've seen are: * Value constraints are named the same on every instance of the value type (this is illegal in SQL Server), * Role names sometimes get used, and sometimes not, in generating names of fields, with the result that foreign key constraints refer to fields that don't exist in the DDL, * NOT NULL fields are declared as such, but not NULL fields, even though the default can be changed, * Extenal uniqueness constraints are generated incorrectly. For example: Entrant has exactly one GivenName Team is a subclass of Entrant Competitor is a subclass of Entrant Competitor has exactly one FamilyName (Entrant.GivenName, Competitor.FamilyName) is unique. Because Competitor is absorbed into Entrant, the uniqueness constraint can be declared as a Unique constraint (but see below), however it's actually generated as a UC across *just* the FamilyName field, which is quite wrong. * Unique constraints across more than one column are generated assuming the wrong semantics for nullable fields. SQL Server only allows one instance of a NULL, not any number. At least some of these errors are not just SQL Server issues, but logical errors in the absorption process. ---------------------------------------------------------------------- >Comment By: Clifford Heath (cjheath) Date: 2007-04-24 12:49 Message: Logged In: YES user_id=1608419 Originator: YES Ok, thanks Kevin. Can I ask that you choose at least one real use case around which to define acceptance tests, and actually do the acceptance testing? It doesn't seem possible that you've compiled or run all of the generated artifacts from previous releases... and if a thing hasn't been tested, it isn't cooked yet! Even a "basic functionality test" is better than nothing. ---------------------------------------------------------------------- Comment By: Kevin M. Owen (kevinowen) Date: 2007-04-24 02:13 Message: Logged In: YES user_id=1014759 Originator: NO We are currently in the process of making several important changes both to the core tool and to the early stages of the generation process. The net result of these changes should be a significant improvement in the quality of the various "artifacts" (including SQL) that we generate. The results from these changes should start showing up over the next few months, and we will hopefully have everything to a stable point to publish a release with these changes around early June. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1705888&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-04-23 16:13:56
|
Bugs item #1705888, was opened at 2007-04-23 06:36 Message generated for change (Comment added) made by kevinowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1705888&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Clifford Heath (cjheath) Assigned to: Nobody/Anonymous (nobody) Summary: Serious correctness issues in generated SQL Initial Comment: I'm using the generated SQL Server code from the Orienteering model (this version is revised from the one posted in a previous bug report) and there are numerous things that either don't run (incorrect SQL) or are just logical errors. Some of the things I've seen are: * Value constraints are named the same on every instance of the value type (this is illegal in SQL Server), * Role names sometimes get used, and sometimes not, in generating names of fields, with the result that foreign key constraints refer to fields that don't exist in the DDL, * NOT NULL fields are declared as such, but not NULL fields, even though the default can be changed, * Extenal uniqueness constraints are generated incorrectly. For example: Entrant has exactly one GivenName Team is a subclass of Entrant Competitor is a subclass of Entrant Competitor has exactly one FamilyName (Entrant.GivenName, Competitor.FamilyName) is unique. Because Competitor is absorbed into Entrant, the uniqueness constraint can be declared as a Unique constraint (but see below), however it's actually generated as a UC across *just* the FamilyName field, which is quite wrong. * Unique constraints across more than one column are generated assuming the wrong semantics for nullable fields. SQL Server only allows one instance of a NULL, not any number. At least some of these errors are not just SQL Server issues, but logical errors in the absorption process. ---------------------------------------------------------------------- >Comment By: Kevin M. Owen (kevinowen) Date: 2007-04-23 09:13 Message: Logged In: YES user_id=1014759 Originator: NO We are currently in the process of making several important changes both to the core tool and to the early stages of the generation process. The net result of these changes should be a significant improvement in the quality of the various "artifacts" (including SQL) that we generate. The results from these changes should start showing up over the next few months, and we will hopefully have everything to a stable point to publish a release with these changes around early June. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1705888&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-04-23 13:36:41
|
Bugs item #1705888, was opened at 2007-04-23 23:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1705888&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Clifford Heath (cjheath) Assigned to: Nobody/Anonymous (nobody) Summary: Serious correctness issues in generated SQL Initial Comment: I'm using the generated SQL Server code from the Orienteering model (this version is revised from the one posted in a previous bug report) and there are numerous things that either don't run (incorrect SQL) or are just logical errors. Some of the things I've seen are: * Value constraints are named the same on every instance of the value type (this is illegal in SQL Server), * Role names sometimes get used, and sometimes not, in generating names of fields, with the result that foreign key constraints refer to fields that don't exist in the DDL, * NOT NULL fields are declared as such, but not NULL fields, even though the default can be changed, * Extenal uniqueness constraints are generated incorrectly. For example: Entrant has exactly one GivenName Team is a subclass of Entrant Competitor is a subclass of Entrant Competitor has exactly one FamilyName (Entrant.GivenName, Competitor.FamilyName) is unique. Because Competitor is absorbed into Entrant, the uniqueness constraint can be declared as a Unique constraint (but see below), however it's actually generated as a UC across *just* the FamilyName field, which is quite wrong. * Unique constraints across more than one column are generated assuming the wrong semantics for nullable fields. SQL Server only allows one instance of a NULL, not any number. At least some of these errors are not just SQL Server issues, but logical errors in the absorption process. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1705888&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-04-13 20:00:27
|
Bugs item #1689349, was opened at 2007-03-27 09:34 Message generated for change (Comment added) made by mcurland You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1689349&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Fixed Priority: 3 Private: No Submitted By: Tyler (tynman) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent constraint coloring for numeric ranges Initial Comment: Not sure if this is by design, but I'm guessing not.... I just created a value range on a Numeric: Unsigned Integer value type. If the range is [1..14], "The possible values of MyValueType are at least 1 to at most 14" is in bolded blue. Any combination of (1..14], (1..14), [1..14) has the "at most"/"at least"/"above"/"below" text in green. I believe the [] bolded blue combination is probably the formatting error. ---------------------------------------------------------------------- >Comment By: Matthew Curland (mcurland) Date: 2007-04-13 13:00 Message: Logged In: YES user_id=1452263 Originator: NO Consistent with changeset #1014. Also added a color option for instance values and bound values to this instead of the objectType category. The blue was correct (these are categorized as quantifiers). If you have other suggestions pipe back in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1689349&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-04-12 17:49:20
|
Bugs item #1688612, was opened at 2007-03-26 11:04 Message generated for change (Comment added) made by mcurland You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1688612&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Tyler (tynman) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot rotate fact types,change constraint display position Initial Comment: Don't know if it's just me (nobody else around me has a running copy of NORMA to test it on), but as of revision 1012 you cannot rotate the fact types. The menus show up fine, and I can swap roles, but selecting "Vertical, rotated ____" does nothing. ---------------------------------------------------------------------- >Comment By: Matthew Curland (mcurland) Date: 2007-04-12 10:49 Message: Logged In: YES user_id=1452263 Originator: NO Fixed in changeset 1013. Some modifications to the code were made to handle multiple shapes for the same element on the same diagram, and the transactions were not committed for the constraint position or orientation menu items. The corresponding properties in the property grid still worked correctly. ---------------------------------------------------------------------- Comment By: Tyler (tynman) Date: 2007-03-27 10:35 Message: Logged In: YES user_id=1303870 Originator: YES Also, the "Constraints on Top/Bottom" toggle doesn't work from the context menu. Works fine from Properties. ---------------------------------------------------------------------- Comment By: Kevin M. Owen (kevinowen) Date: 2007-03-26 11:13 Message: Logged In: YES user_id=1014759 Originator: NO I've confirmed that this isn't working for me either through the context menu right now; we'll get that fixed. In the mean time, you rotate the fact types by directly changing the value of the DisplayOrientation property in the Properties window. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1688612&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-04-12 17:46:59
|
Bugs item #1689384, was opened at 2007-03-27 10:42 Message generated for change (Comment added) made by mcurland You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1689384&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Tyler (tynman) Assigned to: Nobody/Anonymous (nobody) Summary: "Reverse Role Order" does not refresh Initial Comment: In the context window of a fact type under Orientation, clicking "Reverse Role Order" does change the order of the roles, but it does not redraw the role/entity type connection lines. ---------------------------------------------------------------------- >Comment By: Matthew Curland (mcurland) Date: 2007-04-12 10:46 Message: Logged In: YES user_id=1452263 Originator: NO Fixed in changeset 1013. Swap role order (available on the role) always worked, reverse only worked after a display order had been explicitly set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1689384&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-04-02 12:10:11
|
Bugs item #1692839, was opened at 2007-04-02 22:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1692839&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Clifford Heath (cjheath) Assigned to: Nobody/Anonymous (nobody) Summary: Minor issues with printed ORM diagrams Initial Comment: A couple of minor annoyances when printing ORM diagrams. I print to the "MS Publisher Imagesetter" driver to get a Postscript file which I then distill to PDF. These can be lifted nicely into Keynote (Macintosh presentation software), and thankfully appear without a white background. The grey shadow around items that appear on two diagrams is too dense, so that overlapping text is hard to read. The objects are all too small and I can't see how to ask to enlarge them, for example to fill the page, or by a %age etc... Keynote can deal with that, but paper doesn't stretch as well :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1692839&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-04-02 12:04:49
|
Bugs item #1692836, was opened at 2007-04-02 22:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1692836&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Clifford Heath (cjheath) Assigned to: Nobody/Anonymous (nobody) Summary: Missing facts in generated ER model. Initial Comment: I have a new version of my Orienteering schema that seems pretty close to working correctly with the latest (March) CTP - good effort guys, I really like your progress. A lot of things seem much better, though it's still a pity how often I must click the mouse while entering sample populations - tab and cursor keys is the expected way of navigating such things. However, at least one of the facts on the diagram is not present in the MS SQL Server schema. Look for evidence of the "Visit" objectified type. It seems to be completely missing. I didn't even notice until I produced an ER diagram in Enterprise Manager. It's a worry that you don't have a tag attached to each item in the conceptual schema that you set when you absorb it into the final ER schema, as a way of validating that you haven't missed things - or at least of listing the things you had to miss. Is it possible to turn on the ER mode in this CTP and view that diagram here, or is LiveOIAL not far enough advanced to do that yet? Clifford Heath. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1692836&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-03-27 17:42:44
|
Bugs item #1689384, was opened at 2007-03-27 11:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1689384&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tyler (tynman) Assigned to: Nobody/Anonymous (nobody) Summary: "Reverse Role Order" does not refresh Initial Comment: In the context window of a fact type under Orientation, clicking "Reverse Role Order" does change the order of the roles, but it does not redraw the role/entity type connection lines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1689384&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-03-27 17:35:51
|
Bugs item #1688612, was opened at 2007-03-26 12:04 Message generated for change (Comment added) made by tynman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1688612&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tyler (tynman) Assigned to: Nobody/Anonymous (nobody) >Summary: Cannot rotate fact types,change constraint display position Initial Comment: Don't know if it's just me (nobody else around me has a running copy of NORMA to test it on), but as of revision 1012 you cannot rotate the fact types. The menus show up fine, and I can swap roles, but selecting "Vertical, rotated ____" does nothing. ---------------------------------------------------------------------- >Comment By: Tyler (tynman) Date: 2007-03-27 11:35 Message: Logged In: YES user_id=1303870 Originator: YES Also, the "Constraints on Top/Bottom" toggle doesn't work from the context menu. Works fine from Properties. ---------------------------------------------------------------------- Comment By: Kevin M. Owen (kevinowen) Date: 2007-03-26 12:13 Message: Logged In: YES user_id=1014759 Originator: NO I've confirmed that this isn't working for me either through the context menu right now; we'll get that fixed. In the mean time, you rotate the fact types by directly changing the value of the DisplayOrientation property in the Properties window. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1688612&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-03-27 16:36:09
|
Bugs item #1689349, was opened at 2007-03-27 10:34 Message generated for change (Settings changed) made by tynman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1689349&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 3 Private: No Submitted By: Tyler (tynman) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent constraint coloring for numeric ranges Initial Comment: Not sure if this is by design, but I'm guessing not.... I just created a value range on a Numeric: Unsigned Integer value type. If the range is [1..14], "The possible values of MyValueType are at least 1 to at most 14" is in bolded blue. Any combination of (1..14], (1..14), [1..14) has the "at most"/"at least"/"above"/"below" text in green. I believe the [] bolded blue combination is probably the formatting error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1689349&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-03-27 16:34:45
|
Bugs item #1689349, was opened at 2007-03-27 10:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1689349&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tyler (tynman) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent constraint coloring for numeric ranges Initial Comment: Not sure if this is by design, but I'm guessing not.... I just created a value range on a Numeric: Unsigned Integer value type. If the range is [1..14], "The possible values of MyValueType are at least 1 to at most 14" is in bolded blue. Any combination of (1..14], (1..14), [1..14) has the "at most"/"at least"/"above"/"below" text in green. I believe the [] bolded blue combination is probably the formatting error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1689349&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-03-26 18:13:33
|
Bugs item #1688612, was opened at 2007-03-26 11:04 Message generated for change (Comment added) made by kevinowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1688612&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tyler (tynman) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot rotate fact types Initial Comment: Don't know if it's just me (nobody else around me has a running copy of NORMA to test it on), but as of revision 1012 you cannot rotate the fact types. The menus show up fine, and I can swap roles, but selecting "Vertical, rotated ____" does nothing. ---------------------------------------------------------------------- >Comment By: Kevin M. Owen (kevinowen) Date: 2007-03-26 11:13 Message: Logged In: YES user_id=1014759 Originator: NO I've confirmed that this isn't working for me either through the context menu right now; we'll get that fixed. In the mean time, you rotate the fact types by directly changing the value of the DisplayOrientation property in the Properties window. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1688612&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-03-26 18:04:04
|
Bugs item #1688612, was opened at 2007-03-26 12:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1688612&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tyler (tynman) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot rotate fact types Initial Comment: Don't know if it's just me (nobody else around me has a running copy of NORMA to test it on), but as of revision 1012 you cannot rotate the fact types. The menus show up fine, and I can swap roles, but selecting "Vertical, rotated ____" does nothing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1688612&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-03-06 00:28:52
|
Bugs item #1656141, was opened at 2007-02-09 08:16 Message generated for change (Comment added) made by ryane You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1656141&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark (sw_engineer) Assigned to: Nobody/Anonymous (nobody) Summary: Entering new facts in fact editor can dork the graphic model Initial Comment: The fact editor is great. So is the graphic orm that gets built either by entering facts or connecting tool icons. But I notice a subtle interaction as I go through the tutorials in the PPT's. If I have selected a predicate icon in the ORM graphic page and then enter a new fact in the fact editor the program, in essence, overwrites the predicate that already exists. After this behavior occurs it will appear that I have a fact in the fact editor that is not represented in the graphic ORM anymore, even though it was there before. Steps to take to observer this behavior: 1) In the fact editor type a fact like Task(id) starts on Date(mdy) and press control-enter. 2) Using your mouse, select the predicate icon in the graphic orm panel, like you would if you were going to move the predicate icon. 3) Go back to the fact editor and type a fact like Time(stamp) flies like an Arrow(size) and press control-enter. Now in the ORM graphic panel you should observe that there only appears to be one predicate even though the fact editor shows two. It will appear that the second sentence overwrote the first predicate. The cognitive problem, for the user, is he/she isn't alerted to the apparent disappearance of the first fact (or predicate) from the diagram. There is no warning, there is no delete or change confirmation dialog. So in practice, if I'm creating a model and going back and forth between the fact editor and the diagram, moving things around, alternating with adding new facts, I can end up with, fairly easily, a list of facts in the fact editor that are not reflected in the diagram. And unless I'm watching closely, I'm going to miss this divergence between the diagram and the list of facts. Should be easy to fix. I love this tool. Mark ---------------------------------------------------------------------- Comment By: ryan (ryane) Date: 2007-03-05 17:28 Message: Logged In: YES user_id=1735269 Originator: NO Many of the problems are due to having a multi line editor. It makes it really nice for adding lots of facts quickly, but it can cause... "issues" when editing. We have identified many of the issues and we hope to have them taken care of one way or another in the new fact editor. Specifically, we plan to control much more closely what facts are shown in the editor so that it is clearer to the user what they are doing and much harder to cause unexpected behaviors. ---------------------------------------------------------------------- Comment By: Brian Nalewajek (brian27) Date: 2007-02-12 11:54 Message: Logged In: YES user_id=1501525 Originator: NO Hi, I've seen similar issues with the Fact Editor and changes made to the diagram. I am causious whenever the FE window isn't empty, as I'm not certain what the results of a change will be - I guess I don't really use it as an editor much - more just a way to enter new FactTypes. The issue may be related to others where the display of the model gets out of sync with the model - as enumerated in the Object Explorer. This tool will be awsome, because the underlying ORM theory is awsome. The more fully the tool is able to implement the methodology, the better it gets. BRN.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1656141&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-02-14 14:32:37
|
Bugs item #1659791, was opened at 2007-02-14 08:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1659791&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Orion Bühler (orionb) Assigned to: Nobody/Anonymous (nobody) Summary: Deleting Reading in the Reading Editor Initial Comment: When right-clicking a reading in the reading editor, the option to delete the reading is listed, but appears to do nothing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1659791&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-02-12 18:54:41
|
Bugs item #1656141, was opened at 2007-02-09 10:16 Message generated for change (Comment added) made by brian27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1656141&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark (sw_engineer) Assigned to: Nobody/Anonymous (nobody) Summary: Entering new facts in fact editor can dork the graphic model Initial Comment: The fact editor is great. So is the graphic orm that gets built either by entering facts or connecting tool icons. But I notice a subtle interaction as I go through the tutorials in the PPT's. If I have selected a predicate icon in the ORM graphic page and then enter a new fact in the fact editor the program, in essence, overwrites the predicate that already exists. After this behavior occurs it will appear that I have a fact in the fact editor that is not represented in the graphic ORM anymore, even though it was there before. Steps to take to observer this behavior: 1) In the fact editor type a fact like Task(id) starts on Date(mdy) and press control-enter. 2) Using your mouse, select the predicate icon in the graphic orm panel, like you would if you were going to move the predicate icon. 3) Go back to the fact editor and type a fact like Time(stamp) flies like an Arrow(size) and press control-enter. Now in the ORM graphic panel you should observe that there only appears to be one predicate even though the fact editor shows two. It will appear that the second sentence overwrote the first predicate. The cognitive problem, for the user, is he/she isn't alerted to the apparent disappearance of the first fact (or predicate) from the diagram. There is no warning, there is no delete or change confirmation dialog. So in practice, if I'm creating a model and going back and forth between the fact editor and the diagram, moving things around, alternating with adding new facts, I can end up with, fairly easily, a list of facts in the fact editor that are not reflected in the diagram. And unless I'm watching closely, I'm going to miss this divergence between the diagram and the list of facts. Should be easy to fix. I love this tool. Mark ---------------------------------------------------------------------- Comment By: Brian Nalewajek (brian27) Date: 2007-02-12 13:54 Message: Logged In: YES user_id=1501525 Originator: NO Hi, I've seen similar issues with the Fact Editor and changes made to the diagram. I am causious whenever the FE window isn't empty, as I'm not certain what the results of a change will be - I guess I don't really use it as an editor much - more just a way to enter new FactTypes. The issue may be related to others where the display of the model gets out of sync with the model - as enumerated in the Object Explorer. This tool will be awsome, because the underlying ORM theory is awsome. The more fully the tool is able to implement the methodology, the better it gets. BRN.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1656141&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-02-09 15:16:06
|
Bugs item #1656141, was opened at 2007-02-09 10:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1656141&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark (sw_engineer) Assigned to: Nobody/Anonymous (nobody) Summary: Entering new facts in fact editor can dork the graphic model Initial Comment: The fact editor is great. So is the graphic orm that gets built either by entering facts or connecting tool icons. But I notice a subtle interaction as I go through the tutorials in the PPT's. If I have selected a predicate icon in the ORM graphic page and then enter a new fact in the fact editor the program, in essence, overwrites the predicate that already exists. After this behavior occurs it will appear that I have a fact in the fact editor that is not represented in the graphic ORM anymore, even though it was there before. Steps to take to observer this behavior: 1) In the fact editor type a fact like Task(id) starts on Date(mdy) and press control-enter. 2) Using your mouse, select the predicate icon in the graphic orm panel, like you would if you were going to move the predicate icon. 3) Go back to the fact editor and type a fact like Time(stamp) flies like an Arrow(size) and press control-enter. Now in the ORM graphic panel you should observe that there only appears to be one predicate even though the fact editor shows two. It will appear that the second sentence overwrote the first predicate. The cognitive problem, for the user, is he/she isn't alerted to the apparent disappearance of the first fact (or predicate) from the diagram. There is no warning, there is no delete or change confirmation dialog. So in practice, if I'm creating a model and going back and forth between the fact editor and the diagram, moving things around, alternating with adding new facts, I can end up with, fairly easily, a list of facts in the fact editor that are not reflected in the diagram. And unless I'm watching closely, I'm going to miss this divergence between the diagram and the list of facts. Should be easy to fix. I love this tool. Mark ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1656141&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-02-08 17:04:44
|
Bugs item #1627498, was opened at 2007-01-03 21:04 Message generated for change (Comment added) made by brian27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1627498&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Nalewajek (brian27) Assigned to: Nobody/Anonymous (nobody) Summary: IUC from toolbox can't be applied Initial Comment: Hi, I could not get an internal uniqueness constrait from the toolbox (....) to apply to a role or set of roles in a FactType. Selecting the IUC from toolbox allows it to be brought over to the work area, but a do not enter icon appears when it's over a role (as if it doesn't enter or prematurly leaves edit mode). It can't be left in a none role place on the workspace either, and can't be commited to a role by clicking or ddbl clicking. Adding ICUs by rt clicking on a role (or shift for adding roles), works as expected. This is the 12-2006 TCP installed on VS 2005 SP1 BRN.. ---------------------------------------------------------------------- >Comment By: Brian Nalewajek (brian27) Date: 2007-02-08 12:04 Message: Logged In: YES user_id=1501525 Originator: YES Hi Matt, Thanks for the followup. I noticed similar problems with the Toolbox (such as value objects being dropped as entity objects), in the latest CTP. Tried the reset (that took a few moments), and that cleared these types of problems. I suggest you post the reset as S.O.P. for everyone using this CTP - unless there's downside to that for some. Each bit of friction you can remove (and better yet avert), in the mechanics of using the tool, lets users concentrate on the core functionallity. On a related note: By preference, I use the FactEditor and context menu, unless there is no other way than using the Toolbox. Don't know if that's common to ORM users. If it is common, adding more functionality to the FactEditor and context menu would be welcome. You'd know better than I, which is easier to impliment from a developer's persective. If beefing up the FactEditor is easier - all the better; otherwise, well you enjoy challanges, right? Thanks again. BRN.. ---------------------------------------------------------------------- Comment By: Matthew Curland (mcurland) Date: 2007-02-08 10:08 Message: Logged In: YES user_id=1452263 Originator: NO This is probably a toolbox reset issue. Regardless of what we tell VS about the toolbox item versions on our package, it seems to get the toolbox messed up over version changes. We're going to add an HKCU registry entry indicating the last assembly version used to update the toolbox and automatically reset if the assembly is changed. A toolbox reset (right click on the toolbox and 'Reset Toolbox'), please comment further. Note that NORMA toolbox items work best with a click toolbox/click designer. Automatic action activation (the constraint drag lines, etc) does not work for 'drag from the toolbox'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1627498&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-02-08 15:08:56
|
Bugs item #1627498, was opened at 2007-01-03 19:04 Message generated for change (Comment added) made by mcurland You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1627498&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Nalewajek (brian27) Assigned to: Nobody/Anonymous (nobody) Summary: IUC from toolbox can't be applied Initial Comment: Hi, I could not get an internal uniqueness constrait from the toolbox (....) to apply to a role or set of roles in a FactType. Selecting the IUC from toolbox allows it to be brought over to the work area, but a do not enter icon appears when it's over a role (as if it doesn't enter or prematurly leaves edit mode). It can't be left in a none role place on the workspace either, and can't be commited to a role by clicking or ddbl clicking. Adding ICUs by rt clicking on a role (or shift for adding roles), works as expected. This is the 12-2006 TCP installed on VS 2005 SP1 BRN.. ---------------------------------------------------------------------- >Comment By: Matthew Curland (mcurland) Date: 2007-02-08 08:08 Message: Logged In: YES user_id=1452263 Originator: NO This is probably a toolbox reset issue. Regardless of what we tell VS about the toolbox item versions on our package, it seems to get the toolbox messed up over version changes. We're going to add an HKCU registry entry indicating the last assembly version used to update the toolbox and automatically reset if the assembly is changed. A toolbox reset (right click on the toolbox and 'Reset Toolbox'), please comment further. Note that NORMA toolbox items work best with a click toolbox/click designer. Automatic action activation (the constraint drag lines, etc) does not work for 'drag from the toolbox'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1627498&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-02-08 15:04:06
|
Bugs item #1585972, was opened at 2006-10-27 12:58 Message generated for change (Settings changed) made by mcurland You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1585972&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Sterling Bates (sterlingb) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion fails subsetting a role to a subtype arrow Initial Comment: When connecting a subtype constraint between a role and a subtype arrow, an assertion fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1585972&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-02-08 15:02:51
|
Bugs item #1580587, was opened at 2006-10-19 08:15 Message generated for change (Settings changed) made by mcurland You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1580587&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Scot Becker (sabecker) Assigned to: Nobody/Anonymous (nobody) Summary: Display bug in fact editor Initial Comment: When multiple fact types are in the fact editor window and you switch to another window and then switch back to the fact editor, only the last fact type remains in the fact editor window. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1580587&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-02-08 15:02:51
|
Bugs item #1584744, was opened at 2006-10-25 14:48 Message generated for change (Settings changed) made by mcurland You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1584744&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Misc Group: None >Status: Closed Resolution: Accepted Priority: 6 Private: No Submitted By: DBarden (dbarden) Assigned to: Nobody/Anonymous (nobody) Summary: CTP10 - ORM Reading Editor Initial Comment: The ORM Reading Editor seems to 'go blank' after a bit of work. If you click in empty space where some of the Reading Editor objects ought to be then they show up. ---------------------------------------------------------------------- Comment By: Matthew Curland (mcurland) Date: 2006-11-15 23:27 Message: Logged In: YES user_id=1452263 Originator: NO This is a symptom of a larger issue that the NORMA team is begining to work through. As we add more toolwindows to NORMA we continue to add additional DSLTools event listeners. One of them is causing problems, but we don't know which one because we aren't seeing other error messages associated with this report. Basically, an exception is causing event firing to terminate prematurely, so some of our tool windows are getting an ElementEventsBegun event but not an ElementEventsEnded. This essentially leaves the grid-based windows (Reading, Reference Mode, Sample Population) with redraw turned off and no way to turn it back on. Another symptom is that a file reload wil give a whole bunch of duplicate name errors (the name tracking also relies on the event sequence completing). Basically, once you get in this state you should restart. We are designing a mechanism to wrap individual event handlers so that exceptions are isolated and do not cause system breakdowns. We will include this with the next drop. That will also let use track what the current underlying problem is (we don't actually know, this type of bug is just a symptom). A possible culprit (due to its youth and difficulty) is the ORM Context Window. Close the tab, shut down VS, and restart to run without initializing it. ---------------------------------------------------------------------- Comment By: Kevin M. Owen (kevinowen) Date: 2006-11-11 21:38 Message: Logged In: YES user_id=1014759 Thank you for reporting this problem. We have been able to reproduce it, and are trying to work out exactly what is causing it. ---------------------------------------------------------------------- Comment By: Clifford Heath (cjheath) Date: 2006-11-11 17:36 Message: Logged In: YES user_id=1608419 Sorry, I should have read the rest of the bugs list before commenting. It looks like my problem was described by 1441085, VS needing a restart - it seems to work OK now. ---------------------------------------------------------------------- Comment By: Clifford Heath (cjheath) Date: 2006-11-11 17:24 Message: Logged In: YES user_id=1608419 I have this problem in spades. The reading editor never displays correctly, only maybe one time in ten displays anything at all, and only some of those times is it possible to enter the reading text. So it can take more than a minute of clicking around before you can get to enter a single reading - frustrating! It's all but completely broken. Windows Server 2003 running under VMWare. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1584744&group_id=158881 |
From: SourceForge.net <no...@so...> - 2007-02-08 15:02:32
|
Bugs item #1441085, was opened at 2006-03-01 09:58 Message generated for change (Settings changed) made by mcurland You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1441085&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Misc Group: None >Status: Closed Resolution: Accepted Priority: 6 Private: No Submitted By: Bernd VanSkiver (bvanskiver) Assigned to: Nobody/Anonymous (nobody) Summary: Readings Window requires Visual Studio restart Initial Comment: The readings window doesn't work until Visual Studio is restarted after the first start after installing the NOMRA tools. ---------------------------------------------------------------------- Comment By: Brian Nalewajek (brian27) Date: 2006-04-19 21:44 Message: Logged In: YES user_id=1501525 Other windows (such as the Fact Editor, that were minimized would not reopen until I exited and restarted NORMA in VS 2005. During the session when this happened, I had opened other windows (like the web browser) from within VS. Then, noticed the problem when I returned to the model tab. BRN.. ---------------------------------------------------------------------- Comment By: Kevin M. Owen (kevinowen) Date: 2006-03-01 10:29 Message: Logged In: YES user_id=1014759 This is one of several known issues with the Tool Windows when Visual Studio is first started after installing NORMA. We are looking into the best way to fix or prevent this issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1441085&group_id=158881 |