Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - potterm

Pages: 1 ... 4 5 [6]
General Board / Re: DAO Error - EA Build 585
« on: December 09, 2002, 06:35:27 am »
Excellent!  Thanks very much Geoff - now that's what I call impressive problem turn-around!


General Board / DAO Error - EA Build 585
« on: December 09, 2002, 02:15:14 am »
Since upgrading to EA build 585 (Sparx posted a new version over the weekend), I'm now getting the following error whenever I open the properties of some objects within the model:

DAO.Database [3061]
Too few parameters. Expected 2

This doesn't happen to all objects in the model.  Also, the properties dialog still displays once you've dismissed the error - it's just abit annoying.

Does anyone have any idea how to resolve this?


Bugs and Issues / Re: Repository.GetPackageById broken?
« on: March 31, 2011, 01:11:14 am »
I managed to resolve this in the end by re-installing build 864 and selecting the "Repair" option.  Clearly something was updated on my system which caused EA problems and the re-install seems to have fixed it (Windows DLL hell strikes again?).

Bugs and Issues / Re: Repository.GetPackageById broken?
« on: March 31, 2011, 12:20:07 am »
Verify elem and packID are defined.

Thanks qwerty - I can see that both elem and PackId are fine - when it fails I can inspect these variables in the VS debugger.  When this happened in the original add-in I copied the packID and then searched for it in the model (having copied the content to an Access DB) and verified that the packID was present.

Sounds like it might be some local configuration issue then (the worst of all possible problems).  Strange, because all of the other API calls I'm using are working without problem.

Bugs and Issues / Repository.GetPackageById broken?
« on: March 30, 2011, 11:30:22 pm »
I'm having a problem in an AddIn when calling GetPackageById, although for the time being I'm running the code from a test harness (not from EA via the Add-in route).

Anyway, I'm trying to obtain the containing package for an element in the model and get this error:

The server threw an exception. (Exception from HRESULT: 0x80010105 (RPC_E_SERVERFAULT))

To check that this wasn't some sort of resource issue with the AddIn I even built a very small text executable in C# to reproduce it - see code below:

Code: [Select]
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
    class Program
        static void Main(string[] args)
            EA.Repository rep = new EA.Repository();

            EA.Element elem = rep.GetElementByGuid("{16BEFFF9-2983-46d7-BC96-C695731525AD}");
            int packId = elem.PackageID;
            EA.Package pack = rep.GetPackageByID(packId);

The failure happens in the last line of executable code ("EA.Package pack = ...").  The GUID used for the element is just one of the elements in the model.  I've imported the EAP database files into an Access DB and checked that the PackageID reference returned from the element is correct, so I don't think it's a model problem (and besides I've tried it with different elements and with entirely different models and still get the same failure).

Does anyone have any ideas what's causing this (and whether there's a work around)?


P.S. I'm running on Windows 7 Enterprise (no SP) and EA 8.0 build 864.  Addin is built in Visual C# 2010 Express.  Note that all other aspects of the add in (which queries the model extensively) work without problem.

Bugs and Issues / Re: Incorrect List Numbering in RTF Report [SOLVED
« on: December 12, 2009, 09:32:05 am »
I think I've just got to the bottom of this.  Our Linked Documents are created from a linked document template that we created.  The template includes the first entry of the numbered list for the basic path.  When we create a new use case we end up using the template and (I'm guessing) this is causing EA to use the same List Style for the basic path in every document.  When the whole lot is then combined into a single report then the list style continues from where it left off as it runs through each use case.

So the answer / work-around to this seems to be to create the numbered list afresh each time a new linked document is created, rather than using a pre-canned list in the template.

Bugs and Issues / Incorrect List Numbering in RTF Report [SOLVED]
« on: December 12, 2009, 08:28:25 am »

Before I raise a bug report I'd like to confirm that this is not just me misunderstanding how the RTF editor/reporting functions work.  I have a number of use cases, each one with a Linked Document attached.  Inside the linked document we are documenting the use case steps using a numbered list.  The linked document for each use case correctly shows the basic path numbering reset from 1 in each document, like this:

Use Case 1
1. UC1-Step 1
2. UC1-Step 2
3. UC1-Step 3

Use Case 2
1. UC2-Step 1
2. UC2-Step 2
3. UC2-Step 3

I have an RTF report template which I'm using to generate a use case report (i.e. including each linked document) but when I generate the report I get this:

Use Case 1
1. UC1-Step 1
2. UC1-Step 2
3. UC1-Step 3

Use Case 2
4. UC2-Step 1
5. UC2-Step 2
6. UC2-Step 3

This looks like a bug to me because the report is not showing the numbering that each linked document reflects.  Can anyone confirm this and/or offer a work-around?

Thanks in advance.

P.S.  I'm using the basic list numbering that's available from the tool bar in the Linked Document editor.

Bugs and Issues / Re: Setting the REAL default appearance
« on: December 05, 2009, 09:23:59 pm »

Thanks for clearing this up - I've been seeing the same behaviour lately and it's been driving me nuts.  I agree that getting this feature revamped is not going to be quick and easy for Sparx, but a quick fix (which would at least solve the problem for those currently afflicted by this) would be to make the behaviour optional and add a switch into the options dialog.

Presumably the very first time EA places an element of a given type onto a diagram then it will use default appearance attributes.  So why can't we have an option that forces this behaviour in every case?

At work I have a model where the components and actors have all been drawn onto a seq diagram as the first instance of diagram object - so all subseqent cases are elongated.  I guess I could have avoided this (had I known) by using a default model template that contains all element types (at standard size) on dummy diagram, but this shouldn't be necessary in a tool as mature as EA....


Uml Process / Re: EA question
« on: July 30, 2003, 12:56:22 am »

Right click on the class in your diagram, and select "Set Element Parent".  In the resulting dialog you can create a realisation link with any class you care to type in, even if it that class isn't defined in your model.  

If you launch this dialog for your CustomerContactPersonsCollection class, you'll see that EA has added a realisation link to the ArrayList class during the import.


EA doesn't integrate with TortoiseSVN directly - instead you need to point at the standard SVN client tools.  So if you want to use TortoiseSVN (for its Windows Explorer integration) you'd need to install both it and the standard subversion clients.


Pages: 1 ... 4 5 [6]