Jump to content

[SOLVED] problem using Unigine::Widgets


photo

Recommended Posts

well, I just want to create a DialogDate with Unigine::Widgets, my code is very very simple:

#include <core/systems/widgets/widget_dialog.h>
#include <core/systems/widgets/widget_editline.h>
#include <core/systems/widgets/widget_label.h>
#include <core/systems/widgets/widget_vbox.h>

/*
*/
namespace Unigine::Widgets {

   /*
    */
   class DialogDate : Dialog {

  	 WidgetEditLine date_el;

  	 // constructor
  	 DialogDate(string str = 0) : Dialog(str)  {
  		 VBox hbox = new VBox(4, 4);
  		 addChild(hbox, ALIGN_EXPAND);

  		 hbox.addChild(new Label("Date:"), ALIGN_RIGHT);

  		 date_el = new WidgetEditLine();
  		 hbox.addChild(date_el, ALIGN_EXPAND);

  	 }

  	 void setDate(string ds) { date_el.setText(ds); }
  	 string getDate() { return date_el.getText(): }

   };

   /*
    */
   int dialogDate(string &ds) {

  	 DialogDate dialog;

  	 // create dialog
  	 if(dialog == NULL)
  		 dialog = new DialogDate("Enter new Date");

  	 dialog.setDate(ds);

  	 // show dialog
  	 dialog.arrange();
  	 addChild(dialog,ALIGN_OVERLAP | ALIGN_CENTER);
  	 dialog.setPermanentFocus();

  	 // wait dialog
  	 while(dialog.isDone() == 0) wait;

  	 // dialog result
  	 if(dialog.isOkClicked()) ds = dialog.getDate();

  	 // hide dialog
  	 removeChild(dialog);

  	 return dialog.isOkClicked();
   }

} /* namespace Unigine::Widgets */

 

then when I try to use this, the engine keeps telling me following

11:15:46 owner = 0;
11:15:46 core/systems/widgets/widget_editline.h:35: Interpreter::parse(): unknown token "owner"

 

then I decided to test it with a very very simple world,

#include <core/systems/widgets/widget.h>
#include <core/systems/widgets/widget_dialog_file.h>
#include <core/systems/widgets/widget_window.h>

int init() {
   Player player = new PlayerSpectator();
   player.setDirection(vec3(0.755f,-1.0f,0.25f));
   engine.game.setPlayer(player);

using Unigine::Widgets;
// Create Unigine::Widgets::Window
Window window = new Window("Unigine::Widgets::Window");

// Add the widget to the rendered GUI

addChild(window,ALIGN_OVERLAP | ALIGN_CENTER);

   return 1;
}

 

then here comes the following error


11:34:14 if(parent != NULL) parent.removeChild(this);
11:34:14 core/systems/widgets/widget.h:170: Interpreter::parse_expression(): unknown token "NULL" in "parent != NULL" expression

 

What did I miss? or is there something wrong? I think this should be right, because the Tracker are written by Unigine::Widgets, it works fine, but why my codes didn't work?

Link to comment

NULL is defined in unigine.h

you can either include it

or you can use a line like

#define NULL 0

at the head of the file.

 

[edit] happen to be working on widgets today so the code just popped out at me - owner is defined in core/systems/widgets/widget.h [/edit]

Link to comment

ok, got this, I still have to include both core/unigine.h and core/systems/widgets/widget.h.

 

well, just another thought, why not just export these constant value directly from C++ Interpreter?

NULL = 0,
   true = 1,
   false = 0,
   TRUE = 1,
   FALSE = 0,
PI = 3.141592654f,
   PI2 = 6.283185308f,
   PI05 = 1.570796327f,
   SQRT2 = 1.414213562f,
   RAD2DEG = 57.29577951f,
   DEG2RAD = 0.017453293f,
   EPSILON = 1.0e-6f,
   INFINITY = 1.0e+9f,

 

then this must be much more easier to write code that use these "constant"

Link to comment

don't think so. I would read it as "by including these constants via UNIGINE.h the script Compiler has more possibilities for code optimization than in case of c++ pre-definition"

Link to comment
  • 2 weeks later...

Ulf is right about the reason. At first it might be less convenient to keep in mind that you need to include a file, but in the end it's not much of a trouble. In our point of view, if efficient optimization for real-time is at stake, it's worth it.

Link to comment
Ulf is right about the reason. At first it might be less convenient to keep in mind that you need to include a file, but in the end it's not much of a trouble. In our point of view, if efficient optimization for real-time is at stake, it's worth it.

sometimes, optimization is the second against usability. this is public interface, so such things must be done considering this.

also, i think define guards in this case can done the same optimization.

Link to comment
×
×
  • Create New...