Messages

1

General Board / Re: C++ references (and code gen)

« on: June 05, 2005, 04:56:42 pm »

hi,

thanks for responding, especially within the weekend.

but your reply was a bit depressing.  is this likely to improve?  i think ea is great - and thank you for producing such a wonderful thing at such a reasonable price - but this is a pretty serious hole, isn't it? (basic code generation in c++ doesn't work out of the box)

if it's not likely to be fixed soon, is that because code generation generally is quite a low priority, or because c++ itself has annoying details that don't mesh nicely with uml, or for some other reason?

or am i misunderstanding/confused/plain wrong?

thanks again,
andrew

2

General Board / Re: C++ references (and code gen)

« on: June 05, 2005, 08:32:07 am »

more exactly, it seems that i need to surround everything in a namespace scope, since arguments and return values are not qualified.  maybe there's some setting i'm missing?

to recap:
- all my header files have "namespace Bar {...}"
- the source code for Foo, however, has, instead of "namespace ...", the declaration "using Bar::Foo", and arguments and return values have no explicit namespace.

3

General Board / Re: C++ references (and code gen)

« on: June 05, 2005, 08:03:09 am »

ok, it seems that i'm hitting the same problem reported at http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1117614705;start=4#4

the return values from methods are not specified with a namespace, whether thay have a "*" or not.  so either the namespace has to be specified, or the "using" statement has to be modified.

i'm surprised that what seems like basis functionality requires modification of the code generating system.  again, any confirmation that i'm on the right track would be appreciated.  i was expecting this to be less painful...

4

General Board / Re: C++ references (and code gen)

« on: June 04, 2005, 05:37:59 pm »

now i have the sameproblem with return types (pointers).  if i use namespaces and a pointer return time (with a "*" after the type) then the system doesn't recognise Foo* as existing and so doesn't append the correct namespace.

arrrrrgggghh!  how do i get this to work?  please??

5

General Board / Re: C++ references (and code gen)

« on: June 04, 2005, 05:17:57 pm »

ah.  if i put the "&" at the start of the argument name, rather than at the end of the type, this works.

ok, so i guess that makes a strange kind of sense from c++'s binding rules (int * a, b is a pointer and an int, right?), but the "&" is type information, not part of a name.

so i'm still confused - is this really the right solution?  is it going to work for return types, for example?

thanks,
andrew

6

General Board / C++ references (and code gen)

« on: June 04, 2005, 02:58:06 pm »

sorry for yet another newbie question, but how do i indicate that a parameter to a method is a c++ reference?  if i set the type to be Foo& (where "Foo" is a known class) then the autogenerated code does not include Foo.h (which is included if the type is plain Foo).

more generally, am i missing some good documentation somewhere on code generation?  i tried searchng these archives, but had no success, and i also looked at the ea documentation page.

thanks,
andrew

7

General Board / Re: 5.0 diagram scrolling/dragging with mouse

« on: June 05, 2005, 04:44:18 pm »

great!  thanks.  that's fine for me (meaning i don't care if shift never works again, now that i know ctrl+shift does)

8

General Board / 5.0 diagram scrolling/dragging with mouse

« on: June 04, 2005, 09:00:09 am »

hi,

i've just upgraded to 5.0 and the diagram i am editing is no longer dragged by the mouse when i hold down "shift".  nor does the more standard "middle click and then direct".

is there any way to get something like this working?  i can't work out how to do it via the keyboard shortcuts.

that was a really nice feature for me, since i have a 12" screen...

thanks,
andrew

ps also, the "Add-Ins" menu appears twice on the toolbar, where before it was once.  each time it shows the same add-in (one we've written locally).  is that a known bug?