![xojo generic object xojo generic object](https://i.ytimg.com/vi/pyMUY55C3Ss/maxresdefault.jpg)
Given that this is uncommon and that users who need to write code like this are very comfortable with their understanding that the class names are different for each project type, we do not not feel that it is worth the effort and time to combine them. The gain would be that in the rare cases where a user writes code requiring a control class name, they would always use the same name (Button instead of PushButton, WebButton and MobileButton for example). However, that would be an enormous project likely taking two years or more. The desktop shares the same classes across operating systems as does the Web and Mobile too. Could we change it? Could we merge them all (Desktop, Web and Mobile) all into a single set of control classes? After all, we have already done with this the non-user interface-related classes.
XOJO GENERIC OBJECT ANDROID
We have designed the Mobile framework so that it’s API can be shared by both iOS and Android apps. Mobile controls are prefixed with Mobile. Controls would have as similar an API as we can provide while still being separate classes. When we added support for iOS and later the Mobile framework, we continued this design. You instead write code that deals with instances of controls (Button1, TextField2, etc.) using the names of the controls rather than the class names. Fortunately, most of you don’t deal with the control classes directly. This latter case is one that is typically encountered only be very advanced users and fortunately, they can write that code in a way that makes it useful to other users by abstracting them from the details of how it’s done. You also must deal with it when writing code that passes controls around in a generic way where you use typecasting to convert an object back into the specific control type it is.
![xojo generic object xojo generic object](https://www.mbsplugins.de/image/examples2000.jpg)
Occasionally when you write code that has to deal with something specific to a particular control class such as the Pushbutton’s MacButtonStyle, you do so by referencing the class name of the control. There would have been benefits to doing it. This would also have required extensive changes to the Xojo IDE because it also assumes the controls are Desktop controls. Designing and building the Web framework was already an enormous task which would have only become significantly larger had we decided to design it around the existing set of Desktop classes.
![xojo generic object xojo generic object](https://kubadownload.com/site/assets/files/1324/xojo-listbox.png)
At that time we could have decided to simply add the Web functionality to the existing Desktop control classes. In 2011 we introduced the ability to create Web apps. Thus the underlying framework and the Xojo IDE were designed with the assumption that control classes were for the Desktop only. But at that time we weren’t considering Web, let alone Mobile apps. It was obvious then that it was illogical have MacButton, WindowsButton and LinuxButton since we wanted you to be able to select the desktop operating systems you wished to support and then press Build.
XOJO GENERIC OBJECT WINDOWS
While we started with Mac, we planned to support Windows and eventually Linux. When Xojo was initially developed in the mid-1990s, we were only thinking about cross-platform in terms of the desktop.
![xojo generic object xojo generic object](https://docs.xojo.com/images/7/77/Class_Method_Overloading.png)
Given that, you may have wondered why isn’t a button just a button? There are both historical and technical reasons why Xojo has DesktopButton (the new replacement for PushButton), WebButton and MobileButton classes. While there are some differences, controls share most of their events, properties and methods. A button works much the same way in a Web app as it does in a Desktop or Mobile app. If you use Xojo to create projects for more than just one of these targets, you’ve probably noticed that for the most part, controls are very similar across different project types. The primary way we do this is by keeping the process of creating Desktop, Web and Mobile apps as similar as possible. Our vision for Xojo has always been to make it fast and easy for people of varying programming skill levels to create applications.