Bug 144561 - Entering a non-exisiting type in the operation return value combobox should automatically create that class
Summary: Entering a non-exisiting type in the operation return value combobox should a...
Status: CONFIRMED
Alias: None
Product: umbrello
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: RedHat Enterprise Linux Linux
: NOR wishlist
Target Milestone: ---
Assignee: Umbrello Development Group
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-23 11:42 UTC by Ernesto
Modified: 2007-06-11 08:06 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ernesto 2007-04-23 11:42:05 UTC
Version:           1.5.3 (using KDE KDE 3.5.4KDE 1.2KDE 1.2)
Installed from:    RedHat RPMs00RedHat RPMs

In the operation properties dialog I define the return type in the combobox named Type. The combobox should allow me to choose any class defined in the model, appart from the basic ones.
Comment 1 Oliver Kellogg 2007-04-23 23:30:13 UTC
Cannot confirm.
Please give the exact steps that you did.
Are you starting with an empty model?
If not then please attach the XMI file for which this happens.
Comment 2 Oliver Kellogg 2007-04-24 08:57:37 UTC
> Cannot confirm.

I forgot to mention I did not try it with 1.5.3 but with the latest
version, 1.5.7beta1. And also with SVN HEAD on branches/KDE/3.5/kdesdk.
Comment 3 Ernesto 2007-04-24 10:09:36 UTC
The point is that I can select the return value, but this value not always appears in the signature of the function. I think that return values only appear in the signature when they are basic types like bool, int, etc.
Furthermore, the combobox named Type has always the same size; the combobox is not resizable according to the size string of the types. As a consequence, it is not easy to choose the disable return type.
Comment 4 Oliver Kellogg 2007-04-25 06:55:35 UTC
> The point is that I can select the return value, but
> this value not always appears in the signature of the
> function.

Ah. I think I did see this problem once but when I tried to
further investigate, it no longer happened.