Integrating custom controls in Orbiter - Revision history

Phenigma at 02:27, 23 November 2014

2014-11-23T02:27:52Z

@@ Line 75: / Line 75: @@
 First time an event is fired, the registered callbacks of that type are executed first and then Orbiter's code for that event. Returning true in your callback will cancel Orbiter's code executing. Returning false will make Orbiter continue to process the event executing its internal code.
 [[Category:Orbiters]]
 [[Category:Programmer's Guide]]

Tschak909: /* How to send tasks to task manager. */

2010-06-17T04:44:53Z

How to send tasks to task manager.

←Older revision		Revision as of 04:44, 17 June 2010
Line 76:		Line 76:

	== How to send tasks to task manager. ==		== How to send tasks to task manager. ==

			'''This information is deprecated, as we do not use wxWidgets. PLEASE DISREGARD.'''

	Task manager is a proxy between Orbiter and wx widgets. Since Orbiter is running in a different thread then wx widgets's dialogs, we needed a asynchronous method of communicating with WX.		Task manager is a proxy between Orbiter and wx widgets. Since Orbiter is running in a different thread then wx widgets's dialogs, we needed a asynchronous method of communicating with WX.

Wierdbeard65 at 10:08, 5 May 2010

2010-05-05T10:08:34Z

←Older revision		Revision as of 10:08, 5 May 2010
Line 1:		Line 1:
			{{versioninfo}}
	== The concept of screen in Orbiter ==		== The concept of screen in Orbiter ==
	A ''DesignObj'' is a graphic object from Orbiter. Each ''DesignObj'' may be a collection of ''DesignObj'' children and so on. A parent ''DesignObj'' can be associated with a ''screen'', which gives the programmer the possibility to do custom additional actions with that ''DesignObj''.		A ''DesignObj'' is a graphic object from Orbiter. Each ''DesignObj'' may be a collection of ''DesignObj'' children and so on. A parent ''DesignObj'' can be associated with a ''screen'', which gives the programmer the possibility to do custom additional actions with that ''DesignObj''.

Marie.o at 14:02, 13 February 2009

2009-02-13T14:02:19Z

←Older revision		Revision as of 14:02, 13 February 2009
Line 27:		Line 27:
	From other application, the class can be used like this:		From other application, the class can be used like this:

	''SCREEN_SingleCameraViewOnly screenSingleCameraViewOnly(DeviceIDFrom, DeviceIDTo, iPK_Device);''		SCREEN_SingleCameraViewOnly screenSingleCameraViewOnly(DeviceIDFrom, DeviceIDTo, iPK_Device);
			SendCommand(screenSingleCameraViewOnly);''
	''SendCommand(screenSingleCameraViewOnly);''

	ScreenHandler class is derived from ScreenHandlerBase class. The ScreenHandlerBase has a basing implementation for each ''screen'', like this:		ScreenHandler class is derived from ScreenHandlerBase class. The ScreenHandlerBase has a basing implementation for each ''screen'', like this:

	''virtual void SCREEN_QuadViewCameras(long PK_Screen, string sList_PK_Device){ GotoScreen(PK_Screen); }''		virtual void SCREEN_QuadViewCameras(long PK_Screen, string sList_PK_Device){ GotoScreen(PK_Screen); }

	ScreenHandlerBase already demultiplexes each "go to screen" command and calls the right SCREEN_* method and also deserializes the command parameters. In order to add extrafunctionality for that screen, you will need to derive that virtual method in ScreenHandler class (for screens available for all orbiter) or OSDScreenHandler class (which has the handlers only for linux OSD Orbiter).		ScreenHandlerBase already demultiplexes each "go to screen" command and calls the right SCREEN_* method and also deserializes the command parameters. In order to add extrafunctionality for that screen, you will need to derive that virtual method in ScreenHandler class (for screens available for all orbiter) or OSDScreenHandler class (which has the handlers only for linux OSD Orbiter).
Line 42:		Line 41:
	So far, this is the list with callback types you can register:		So far, this is the list with callback types you can register:

	~~<pre>~~		enum CallBackType
	enum CallBackType		{
	{
	cbUnused,		cbUnused,
	cbDataGridSelected,		cbDataGridSelected,
Line 62:		Line 60:
	cbOnRenderScreen,		cbOnRenderScreen,
	cbOnGotoScreen		cbOnGotoScreen
	};		};
	~~</pre>~~

	For each type of callback, your registered callback can be notified when an event is fired with extra data. That extra data is actually a derived class from CallBackData class.		For each type of callback, your registered callback can be notified when an event is fired with extra data. That extra data is actually a derived class from CallBackData class.
Line 85:		Line 82:
	Orbiter sends "tasks" to WX via TaskManager. A task has associated info about the dialog type, callback type, callback data and a task id (which is generated and managed by TaskManager). To do this, there are two methods in TaskManager :		Orbiter sends "tasks" to WX via TaskManager. A task has associated info about the dialog type, callback type, callback data and a task id (which is generated and managed by TaskManager). To do this, there are two methods in TaskManager :

	void AddTask(Task *Event);		void AddTask(Task *Event);
	void AddTaskAndWait(Task *Event);		void AddTaskAndWait(Task *Event);

	AddTask allows you to send info to WX asynchronously. AddTaskAndWait allows you to send info to WX synchronously. Once the task is added in the queue, a conditional wait is made in the queue and when a task is processed, it wakes up and verifies if the task with the id added was processed or not. If yes, the method returns.		AddTask allows you to send info to WX asynchronously. AddTaskAndWait allows you to send info to WX synchronously. Once the task is added in the queue, a conditional wait is made in the queue and when a task is processed, it wakes up and verifies if the task with the id added was processed or not. If yes, the method returns.
Line 97:		Line 94:
	To create a "speed control" wxdialog, we'll do a :		To create a "speed control" wxdialog, we'll do a :

	SpeedControlCallBackData *pSpeedControlData = new SpeedControlCallBackData(plutoRect);		SpeedControlCallBackData *pSpeedControlData = new SpeedControlCallBackData(plutoRect);
			Task *pTask = TaskManager::Instance().CreateTask(cbOnDialogCreate, E_Dialog_SpeedControl, pSpeedControlData);
	Task *pTask = TaskManager::Instance().CreateTask(cbOnDialogCreate, E_Dialog_SpeedControl, pSpeedControlData);		TaskManager::Instance().AddTaskAndWait(pTask);

	TaskManager::Instance().AddTaskAndWait(pTask);


Line 107:		Line 102:
	If we want to now there to create and delete the dialog, we may want to create a screen for the parent object of wx control and register callbacks in overriden SCREEN_* method from the screen handler class like this:		If we want to now there to create and delete the dialog, we may want to create a screen for the parent object of wx control and register callbacks in overriden SCREEN_* method from the screen handler class like this:

	RegisterCallBack( cbOnDialogCreate, (ScreenHandlerCallBack)&OSDScreenHandler::SpeedControlCreate, new PositionCallBackData() );		RegisterCallBack( cbOnDialogCreate, (ScreenHandlerCallBack)&OSDScreenHandler::SpeedControlCreate, new PositionCallBackData() );

	RegisterCallBack( cbOnDialogDelete, (ScreenHandlerCallBack)&OSDScreenHandler::SpeedControlDelete, new PositionCallBackData() );		RegisterCallBack( cbOnDialogDelete, (ScreenHandlerCallBack)&OSDScreenHandler::SpeedControlDelete, new PositionCallBackData() );

Rwilson131 at 13:01, 8 October 2007

2007-10-08T13:01:09Z

←Older revision		Revision as of 13:01, 8 October 2007
Line 1:		Line 1:
	~~{{Plutoperm}}~~


	== The concept of screen in Orbiter ==		== The concept of screen in Orbiter ==
	A ''DesignObj'' is a graphic object from Orbiter. Each ''DesignObj'' may be a collection of ''DesignObj'' children and so on. A parent ''DesignObj'' can be associated with a ''screen'', which gives the programmer the possibility to do custom additional actions with that ''DesignObj''.		A ''DesignObj'' is a graphic object from Orbiter. Each ''DesignObj'' may be a collection of ''DesignObj'' children and so on. A parent ''DesignObj'' can be associated with a ''screen'', which gives the programmer the possibility to do custom additional actions with that ''DesignObj''.
Line 117:		Line 114:
	The new UI will allows you to manage wx widget's dialog as popups, via PopupManager class. *comming soon*		The new UI will allows you to manage wx widget's dialog as popups, via PopupManager class. *comming soon*
	[[Category:Orbiters]]		[[Category:Orbiters]]
			[[Category:Programmer's Guide]]

Lozzo at 03:04, 1 October 2007

2007-10-01T03:04:39Z

←Older revision		Revision as of 03:04, 1 October 2007
Line 116:		Line 116:

	The new UI will allows you to manage wx widget's dialog as popups, via PopupManager class. *comming soon*		The new UI will allows you to manage wx widget's dialog as popups, via PopupManager class. *comming soon*
			[[Category:Orbiters]]

T0ny at 04:31, 25 March 2007

2007-03-25T04:31:30Z

←Older revision		Revision as of 04:31, 25 March 2007
Line 1:		Line 1:
	{{Plutoperm}}		{{Plutoperm}}


	== The concept of screen in Orbiter ==		== The concept of screen in Orbiter ==

T0ny at 04:31, 25 March 2007

2007-03-25T04:31:17Z

←Older revision		Revision as of 04:31, 25 March 2007
Line 1:		Line 1:
	{~~\| style="background: #FFCFCF; border: 1px dotted black;"~~		{{Plutoperm}}
	\|-
	\|This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007. In general any information should apply to LinuxMCE. However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.
	\|}


	== The concept of screen in Orbiter ==		== The concept of screen in Orbiter ==

T0ny: /* ScreenHandler and how to register a callback */

2007-03-25T04:25:51Z

ScreenHandler and how to register a callback

←Older revision		Revision as of 04:25, 25 March 2007
Line 48:		Line 48:
	So far, this is the list with callback types you can register:		So far, this is the list with callback types you can register:

			<pre>
	enum CallBackType		enum CallBackType
	{		{
Line 68:		Line 69:
	cbOnGotoScreen		cbOnGotoScreen
	};		};
			</pre>

	For each type of callback, your registered callback can be notified when an event is fired with extra data. That extra data is actually a derived class from CallBackData class.		For each type of callback, your registered callback can be notified when an event is fired with extra data. That extra data is actually a derived class from CallBackData class.

T0ny: Converted table to wiki from html

2007-03-25T04:25:23Z

Converted table to wiki from html

←Older revision		Revision as of 04:25, 25 March 2007
Line 1:		Line 1:
	~~<table width="100%"> <tr><td bgcolor~~="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007. In general any information should apply to LinuxMCE. However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.~~</td></tr> </table>~~== The concept of screen in Orbiter ==		{\| style="background: #FFCFCF; border: 1px dotted black;"
			\|-
			\|This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007. In general any information should apply to LinuxMCE. However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.
			\|}


			== The concept of screen in Orbiter ==
	A ''DesignObj'' is a graphic object from Orbiter. Each ''DesignObj'' may be a collection of ''DesignObj'' children and so on. A parent ''DesignObj'' can be associated with a ''screen'', which gives the programmer the possibility to do custom additional actions with that ''DesignObj''.		A ''DesignObj'' is a graphic object from Orbiter. Each ''DesignObj'' may be a collection of ''DesignObj'' children and so on. A parent ''DesignObj'' can be associated with a ''screen'', which gives the programmer the possibility to do custom additional actions with that ''DesignObj''.