For more information about this bug, visit

peter [dot] soetens [..] ... changed:

What |Removed |Added
---------------------------------------------------------------------------
Resolution| |FIXED
Status|REOPENED |RESOLVED

------- Comment #5 from peter [dot] soetens [..] ... 2007-04-30 14:54

$ svn ci -m"Fix bug #385: Component starts anyway it was not configured yet.
> Add an optional parameter to the TaskContext/TaskCore constructor indicating the initial state.
> Adapt manuals
> Write unit test.
> "
Sending rtt/doc/xml/images/ComponentStates.svg
Sending rtt/doc/xml/orocos-task-context.xml
Sending rtt/src/TaskContext.cpp
Sending rtt/src/TaskContext.hpp
Sending rtt/src/TaskCore.cpp
Sending rtt/src/TaskCore.hpp
Sending rtt/tests/generictask_test_3.cpp
Transmitting file data .......
Committed revision 27942.

For more information about this bug, visit
A comment was added:
------- Comment #4 from ruben [dot] smits [..] ... 2007-04-27 14:46

(In reply to comment #3)
> So mTaskState = PreOperational will have to do.
>
> That's what you get when writing out of the top of your head...
>
> this->mTaskState = PreOperational;
>
> should do for now in your constructor. There is a getTaskState() though.
> I'm not keen on letting the user modify this variable directly. Maybe we need
> to pass it using the constructor:
>
> MyComponent() : TaskContext("name", PreOperational) { ... }
>
> ? That would also make the initial state selection more explicit to users.

That's maybe a better idea, and giving a default value keeps it backwards
compatible.

Ruben

For more information about this bug, visit
A comment was added:
------- Comment #3 from peter [dot] soetens [..] ... 2007-04-27 14:38

So mTaskState = PreOperational will have to do.(In reply to comment #2)
> Adding this line in my constructor gives me the following compiling error:

That's what you get when writing out of the top of your head...

this->mTaskState = PreOperational;

should do for now in your constructor. There is a getTaskState() though.
I'm not keen on letting the user modify this variable directly. Maybe we need
to pass it using the constructor:

MyComponent() : TaskContext("name", PreOperational) { ... }

? That would also make the initial state selection more explicit to users.

Peter

For more information about this bug, visit

ruben [dot] smits [..] ... changed:

What |Removed |Added
---------------------------------------------------------------------------
Resolution|INVALID |
Status|RESOLVED |REOPENED

------- Comment #2 from ruben [dot] smits [..] ... 2007-04-27 14:24

Adding this line in my constructor gives me the following compiling error:

/home/rsmits/orocos/orocos-apps/applications/dynamical_registration/new_version/src/IB_Tracking.cpp:
In constructor ‘IB_Tracking::IB_Tracking(std::string,
std::string)’:
/home/rsmits/orocos/orocos-apps/applications/dynamical_registration/new_version/src/IB_Tracking.cpp:96:
error: ‘class IB_Tracking’ has no member named
‘setTaskState’

I also cannot find this function in the API documentation (following the link
you send me)

i'm using revision 27908

Ruben

For more information about this bug, visit

peter [dot] soetens [..] ... changed:

What |Removed |Added
---------------------------------------------------------------------------
Resolution| |INVALID
Status|NEW |RESOLVED

------- Comment #1 from peter [dot] soetens [..] ... 2007-04-27 14:14

(In reply to comment #0)
> Hi,
>
> i was trying out the new states of the TaskContext and found the following
> error:
>
> if i start my component without calling configure() first (i implemented the
> configureHook()-function), my component starts anyway. I thought the component
> would not start until configure was called?

As documented[*], you need to set in your component's constructor:

this->setTaskState( PreOperational );

to force the 'user' of your component to do 'configure()'. Implementing
configureHook() is not enough.

Peter

[*]