Re: [Fwd: [Crystal-cvs] SF.net SVN: crystal:[38136] CS/branches/soc2012/editor]

> Right now, the csVariant* from graphMain, line 393 seems to be leaking.
> I know it's not much but still...

It seems a priori correct to me. The user class holds a temporary
reference to the iModifiableParameter that is allocated within the
iModifiableDescription (and that will remain as long as it will). There
are no call to a 'new', therefore no need for a call to a 'delete'.

Btw, the csRefArray of parameters in csBasicModifiableDescription
(graphnode.h) is not necessary since the allocation of the resource is
tightly linked to the one of the iModifiableDescription, therefore the
csBasicModifiableDescription should control itself its resources. To
summarize what I mean: the csRefArray should be replaced by a csArray.

> Was there a problem with unique_ptr<>?

This feature is quite recent in C++, and may a priori be problematic for
portability reasons.
CS has its own smart pointer system, it's better to not mix them.

> Error: Can't create window of class wxGLCanvasClassNR (error 0: the
> operation completed successfully.)

The initialization of the wx canvas within CS is a bit tricky, although
the exact problem here is not clear to me.

It's probably better if your test application can be completely
independant to the wx canvas, so that we can test them separately.

The better to test it with a 3D canvas is with the cseditor. I'm still
working on it, I'm a bit slow, I know :), but it's getting closer and
closer.

Meanwhile, there is still the event system, the translations and the
slider that can be done.

Also, the classes in varedittest are currently very badly named for
historical reasons, can you change that?

> Also, once I get that in place, how would I make, say, a particle
> system/ particle type iModifiable?

You would edit the files in 'plugins/mesh/particles/object', and add the
iModifiable interface and implementation to both the particle mesh and the
particle mesh factory.

> I believe it would make sense to edit
> all the code itself, since I don't think that merging it back into the
> trunk with just the added implementation of iModifiable would break
> anything.

Not sure of what you mean here, but in all cases, you should probably keep
your work within your branch, and edit the particle and whatever other
files within it.

> My final question might sound a tad vague, but anyway, do you think
> there is a way to avoid pieces of code like the following?
>
> if(id == id_name) {
>      name = value.GetString();
>      return true;
>    } else if(id == id_job) {
>      job = value.GetString();
>      return true;
>    } else if ...
> ...
>    } else if(id == id_color) {
>      color = value.GetColor();
>      return true;
>    }

This one is tricky...

The cleanest might be to use a switch but this may not be possible at all,
because the potential ID value's are not available at compilation time.

Some other suggestions?



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/