Get the Unity "Evas_Object* win" object?

I need to be able to get the base C "Evas_Object* win" object Unity creates with "elm_win_util_standard_add".

I need this so I can make a plugin that uses it and pass it into other native methods like "Evas_Object* popup = elm_popup_add(win);"

Is this object exposed in Unity? Can't seem to find any Tizen method to get the currently active one.

 

For BB10 I had to do a total hack to merge two window contexts into the global window group. BB10 had an API that would allow me to do this without knowing what Unity's window handle actually was.

Right now i'm talking to a Tizen / Enlightenment expert on how I might get this "Evas_Object* win" object without Unity exposing it. So far he says its impossible, even more so when they update to Wayland away from x11.

I must have Unity's main "Evas_Object* win" object it creates to almost do anything with Tizen as every API like popups even require it. BB10 didn't require this so much.

Do you think you could expose this object via a method I could "DLLImport" in C# to get an IntPtr from it? Without it I can't do anything, not even show a simple OK/Cancel box...

 

As an example to init the Ok/Cancel popup box I call: "Evas_Object* popup = elm_popup_add(ad->win);"
Notice "ad->win" this is the object created in Unity when calling "ad->win = elm_win_util_standard_add(...);".

I must have that "win" handle to create a MessageBox dlg. So if there was a static reference to it I could get from invoking a C method Unity exposes that would be everything I need.

 

This is very specific to Tizen. Anyway we could get that object exposed in a future update? If there's a better idea i'm all ears but don't think there is and almost all Tizen objects require it. Ad frameworks are going to require this ect.

 

Or you could expose this via a C# tizen API. What ever is easier doesn't matter as long as you can get that "win" handle exposed.

 

Thats awesome! Thanks for the heads up.

 

Any chance this object might be exposed in Unity 5.2?
I'm happy to give any info I can on the matter that might help if there is still confusion regarding this.

 

Wow... thanks for killing the plugin market before it even starts... So we can't make a plugin that even shows a NATIVE Ok/Cancel box, IAP dlg, (How are Ad frameworks going to work without this), ect, because someone doesn't "feel" its needed??

Where is the logic here because I don't see it? Time? How would adding a single line of "extern C" and "C#" code take any time...? Security? How would exposing this cause any security issues? I don't want to insult but maybe its just incompetence, who is making these final determinations on this team and why? Is Unity that crapped out under the hood this is really more effort then its worth. One more point for the Unreal Engine as I would never have any of these silly issues with that engine. The is beyond stupid unless a work around is possible and posted I don't know about.

This choice makes no sense and is frustrating sorry for this reaction but I can't help it. Unity is starting to NOT be a profitable market tool anymore... sad rly.

Can we take the sugar coating off the BS a little and explain??

 

If you don't want your developers to support Tizen and build useful plugins for this platform then simply don't tell that Unity is supporting Tizen!
I don't understand what's the problem in adding bunch of lines of code that help Asset developers to make a useful plugins for your customers!!!
I hope you'll change your opinion and help @zezba9000 to add Tizen support to his plugin, he's an excellent developer and he provide an excellent plugins for your engine, please support it and do not lose it.

 

This is great news, sorry for any negativity this may have caused.
I'll be sure to make use of this when available.