kimcinoo
/
efl
forked from enlightenment/efl
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
efl/src/lib/elementary/elm_multibuttonentry_eo.leg...

270 lines
8.4 KiB
C
Raw Permalink Normal View History

elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
#ifndef _ELM_MULTIBUTTONENTRY_EO_LEGACY_H_
#define _ELM_MULTIBUTTONENTRY_EO_LEGACY_H_
#ifndef _ELM_MULTIBUTTONENTRY_EO_CLASS_TYPE
#define _ELM_MULTIBUTTONENTRY_EO_CLASS_TYPE
typedef Eo Elm_Multibuttonentry;
#endif
#ifndef _ELM_MULTIBUTTONENTRY_EO_TYPES
#define _ELM_MULTIBUTTONENTRY_EO_TYPES
#endif
/**
* @brief Control if the multibuttonentry is to be editable or not.
*
* @param[in] obj The object.
* @param[in] editable If @c true, user can add/delete item in
* multibuttonentry, if not, the multibuttonentry is non-editable.
*
* @since 1.7
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API void elm_multibuttonentry_editable_set(Elm_Multibuttonentry *obj, Eina_Bool editable);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/**
* @brief Control if the multibuttonentry is to be editable or not.
*
* @param[in] obj The object.
*
* @return If @c true, user can add/delete item in multibuttonentry, if not,
* the multibuttonentry is non-editable.
*
* @since 1.7
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API Eina_Bool elm_multibuttonentry_editable_get(const Elm_Multibuttonentry *obj);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/**
* @brief Control the multibuttonentry to expanded state.
*
* In expanded state, the complete entry will be displayed. Otherwise, only
* single line of the entry will be displayed.
*
* @param[in] obj The object.
* @param[in] expanded The value of expanded state. Set this to @c true for
* expanded state. Set this to @c false for single line state.
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API void elm_multibuttonentry_expanded_set(Elm_Multibuttonentry *obj, Eina_Bool expanded);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/**
* @brief Control the multibuttonentry to expanded state.
*
* In expanded state, the complete entry will be displayed. Otherwise, only
* single line of the entry will be displayed.
*
* @param[in] obj The object.
*
* @return The value of expanded state. Set this to @c true for expanded state.
* Set this to @c false for single line state.
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API Eina_Bool elm_multibuttonentry_expanded_get(const Elm_Multibuttonentry *obj);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/**
* @brief Set a function to format the string that will be used to display the
* hidden items counter.
*
* If @c format_function is @c NULL, the default format will be used, which is
* $"... + %d".
*
* @param[in] obj The object.
* @param[in] format_function Format_function The actual format function
* @param[in] data Data User data to passed to @c format_function
*
* @since 1.9
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API void elm_multibuttonentry_format_function_set(Elm_Multibuttonentry *obj, Elm_Multibuttonentry_Format_Cb format_function, const void *data);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/**
* @brief Get a list of items in the multibuttonentry
*
* @param[in] obj The object.
*
* @return The list of items, or NULL if none
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API const Eina_List *elm_multibuttonentry_items_get(const Elm_Multibuttonentry *obj);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/**
* @brief Get the first item in the multibuttonentry
*
* @param[in] obj The object.
*
* @return The first item, or NULL if none
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API Elm_Widget_Item *elm_multibuttonentry_first_item_get(const Elm_Multibuttonentry *obj);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/**
* @brief Get the last item in the multibuttonentry
*
* @param[in] obj The object.
*
* @return The last item, or NULL if none
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API Elm_Widget_Item *elm_multibuttonentry_last_item_get(const Elm_Multibuttonentry *obj);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/**
* @brief Get the entry of the multibuttonentry object
*
* @param[in] obj The object.
*
* @return The entry object, or NULL if none
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API Efl_Canvas_Object *elm_multibuttonentry_entry_get(const Elm_Multibuttonentry *obj);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/**
* @brief Get the selected item in the multibuttonentry
*
* @param[in] obj The object.
*
* @return The selected item, or NULL if none
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API Elm_Widget_Item *elm_multibuttonentry_selected_item_get(const Elm_Multibuttonentry *obj);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/**
* @brief Prepend a new item to the multibuttonentry
*
* See @ref Efl.Object.invalidate to delete the item.
*
* @param[in] obj The object.
* @param[in] label The label of new item
* @param[in] func The callback function to be invoked when this item is
* pressed.
* @param[in] data The pointer to the data to be attached
*
* @return A handle to the item added or NULL if not possible
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API Elm_Widget_Item *elm_multibuttonentry_item_prepend(Elm_Multibuttonentry *obj, const char *label, Evas_Smart_Cb func, void *data);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/** Remove all items in the multibuttonentry.
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API void elm_multibuttonentry_clear(Elm_Multibuttonentry *obj);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/**
* @brief Remove a filter from the list
*
* Removes the given callback from the filter list. See
* elm_multibuttonentry_item_filter_append() for more information.
*
* @param[in] obj The object.
* @param[in] func The filter function to remove
* @param[in] data The user data passed when adding the function
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API void elm_multibuttonentry_item_filter_remove(Elm_Multibuttonentry *obj, Elm_Multibuttonentry_Item_Filter_Cb func, void *data);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/**
* @brief Add a new item to the multibuttonentry before the indicated object
* reference.
*
* See @ref Efl.Object.invalidate to delete the item.
*
* @param[in] obj The object.
* @param[in] before The item before which to add it
* @param[in] label The label of new item
* @param[in] func The callback function to be invoked when this item is
* pressed.
* @param[in] data The pointer to the data to be attached
*
* @return A handle to the item added or NULL if not possible
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API Elm_Widget_Item *elm_multibuttonentry_item_insert_before(Elm_Multibuttonentry *obj, Elm_Widget_Item *before, const char *label, Evas_Smart_Cb func, void *data);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/**
* @brief Append a new item to the multibuttonentry
*
* See @ref Efl.Object.invalidate to delete the item.
*
* @param[in] obj The object.
* @param[in] label The label of new item
* @param[in] func The callback function to be invoked when this item is
* pressed.
* @param[in] data The pointer to the data to be attached
*
* @return A handle to the item added or NULL if not possible
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API Elm_Widget_Item *elm_multibuttonentry_item_append(Elm_Multibuttonentry *obj, const char *label, Evas_Smart_Cb func, void *data);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/**
* @brief Prepend a filter function for text inserted in the Multibuttonentry
*
* Prepend the given callback to the list. See
* elm_multibuttonentry_item_filter_append() for more information
*
* @param[in] obj The object.
* @param[in] func The function to use as text filter
* @param[in] data User data to pass to @c func
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API void elm_multibuttonentry_item_filter_prepend(Elm_Multibuttonentry *obj, Elm_Multibuttonentry_Item_Filter_Cb func, void *data);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/**
* @brief Append an item filter function for text inserted in the
* Multibuttonentry
*
* Append the given callback to a list. This function is called whenever any
* text is inserted into the Multibuttonentry, with the text to be inserted as
* a parameter. The callback function is free to alter the text in any way it
* wants but must free the given pointer and update it. If the new text is to
* be discarded, the function can free it and set it text parameter to NULL.
* This will also prevent any following filters from being called.
*
* @param[in] obj The object.
* @param[in] func The function to use as item filter
* @param[in] data User data to pass to @c func
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API void elm_multibuttonentry_item_filter_append(Elm_Multibuttonentry *obj, Elm_Multibuttonentry_Item_Filter_Cb func, void *data);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
/**
* @brief Add a new item to the multibuttonentry after the indicated object
*
* See @ref Efl.Object.invalidate to delete the item.
*
* @param[in] obj The object.
* @param[in] after The item after which to add it
* @param[in] label The label of new item
* @param[in] func The callback function to be invoked when this item is
* pressed.
* @param[in] data The pointer to the data to be attached
*
* @return A handle to the item added or NULL if not possible
*
* @ingroup Elm_Multibuttonentry_Group
*/
elementary: Rename EAPI macro to ELM_API in Elementary library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-10-11 09:00:04 -07:00
ELM_API Elm_Widget_Item *elm_multibuttonentry_item_insert_after(Elm_Multibuttonentry *obj, Elm_Widget_Item *after, const char *label, Evas_Smart_Cb func, void *data);
elm_multibuttonentry*: remove all legacy usage from eo files this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8185
2019-03-05 14:00:37 -08:00
#endif