Andr:
As far as I understand, you have a window good size (FileMaker): set the Xojo Window using that size (in Xojo IDE).
This, I do not understand (my poor english or I am tired). Care to explain ?
[quote=441144:@AndrvanHaren]Just wondering: what is a common window size setup? I went terrible wrong in FM at the start by creating my own larger window size and the windows turned out far too large. I had to redo all the layouts after that.
Xojo opens at 600 * 400, which looks very small to create layouts on. There is also the issue that every user will have another Display setting. How do I take this into account with the window sizes in Xojo?[/quote]
I think a good strategy here would be to design the window layout to fit a ‘lowest common denominator’ of screens (1280 x 800 maybe?) and then make the layout expand if/when the user expands the window… either by dragging the edges or going full screen.
In web design, we call this ‘responsive’ design in that the layout responds to the size of the browser window depending on the size of the viewer’s screen. Are they using an iMac or a MacBook… or an iPhone? The layout should respond to this and be able to adjust itself accordingly.
Xojo has always had this ability to some degree. You’ll notice that controls can be locked by their edges to match (or not match) the edges of the window they’re in. You can use this to make the controls in the window react the way you want them to when the user resizes the window.
I too came from a FileMaker background and I can relate to your questions. To my chagrin, Xojo lacks some of the connectivity between database tables and columns and the interface (read: ‘layout’). In FMP, this relationship is automatic… in fact, you can’t add a field to a layout if there isn’t a corresponding column in a table. In Xojo, you’ll have to create your database first (either in code or using an external editor) and then ‘wire up’ the layout to match the schema. It’s far more manual, but not impossible and the results can be worth it since your application will be far more polished than any FMP could deliver.
I look forward to your future questions to see how you progress. Wait until you get to date fields! 
“In Xojo, you’ll have to create your database first (either in code or using an external editor) and then ‘wire up’ the layout to match the schema.”
Yes, I was wondering about this. Like you said, in FM you start by creating the tables for the categories you are going to use. But how do you do this in Xojo? I started yesterday with the layout with the idea to hook it up later to the engine to make everything work and being saved correctly. Where and how do you create the tables in Xojo?
If you want to use SQLite, go there:
http://documentation.xojo.com/api/databases/sqlitedatabase.html
you will find sample code to create the file, then add TABLE, etc.
There are (certainly) examples in the Xojo application folder.
this will be more focused on the IDE for creating database :
https://documentation.xojo.com/topics/databases/supported_engines/sqlite/sqlite_basics.html
[quote=441290:@Jean-Yves Pochez]this will be more focused on the IDE for creating database :
https://documentation.xojo.com/topics/databases/supported_engines/sqlite/sqlite_basics.html[/quote]
This is perfect, thanks!
As a newbie still evaluating Xojo, I see Xojo has a programming language with a GUI. Strictly speaking it’s not really a RAD tool, IMO. Yes, the GUI is RAD, but the rest - read the quote above. There’s so much missing in Xojo it seems to me, particularly on the web side- dropdown, edit-comb, date/time picker controls, field masks, complete lack of data binding on any level, etc etc etc. Fortunately there’s a large 3rd party market which provides many or all of those. You just have to factor that into your pricing. You do get what seems to be a high level of granular control - but you gotta work for it, that’s for sure. But speaking from experience using RAD db tools, esp. on the web side, those tools you often spend much of your time fighting them to bend them to your will with mixed results. So you often lose much of the time saving benefit of the “RAD” part. Either way, take your chances.
Peter, FileMaker has a UI that talks to its own database. Xojo can use any number of different databases, not all of which implement the same concepts in the same way. You cannot expect the same level of integration between the UI and the database as with a special purpose tool such as Filemaker (or Access in the Windows realm).
So, you need to do some of the work because the assumption that the Filemaker UI makes that you are using the Filemaker database, cannot exist in Xojo. If Xojo was another FileMaker (or Access), I would not be using it. Remember, Xojo is far more than just a “RAD db tool”.
FileMaker is a Database with a dedictated programming language , as is Access
while Xojo is a programming language that can use many different types of database engines
So, yes Xojo is very much a RAD tool, just that you can RAD more than just database applications
on the other hand, it is not as raddish as FileMaker when it comes to building database applications, as others already stated here. But with some experience if none of the mentioned solutions fits your needs , you can start to create your own set of controls that matches exactly your desired behaviour and can be (almost) as comfortable as FileMaker.
If the Xojo-built plugins with internal GUI should ever come, delete the almost.
I would say “better” because you can build it the way you want it. but yes this takes time. it’s not built-in.
Concerning the behaviour: Agreed.
I was thinking of such things like assigning relations graphically where in Xojo you have to be verbose.
Thats the tricky part with a rad tool
If you make assumptions that “every app is a database app” you end up with filemaker or access where making an app that ISN’T a database based app drags one along anyway
And if you want a more general purpose tool (which Xojo is) then you dont have a “database focused tool” - but there’s certainly no reason that it would not have things like data bound controls (listbox bound to a data source, etc)
It just doesnt
And the old way of doing it was not very scalable. A bound listbox didnt page data. Using the data control meant you crippled the listbox and a lot of the things it does. Same fo other controls.
A toolbox of data aware controls would be welcome - so who is going to make some ? 
and sold it at $150 ?
FM is not cheap - to buy or to deploy
Why should Xojo be any significant amount less IF thats the capabilities people want ?
There are a lot of people who want Xojo to include “everything”, and I do mean everything, in the license they pay.
I would expect that IF Xojo did this they would only include all the data driven bits as part of a pro or enterprise licenses. It would be a huge investment of time & effort to do and, IMHO, unlikely to be what most personal license holders would use.
Never mind how Xojo gets from what it is now to something like VB with a ton of data driven add ons so you can quickly create applications like in FM. Thats a different question entirely. They’d have to invest a lot of time & $ into this and probably not have anything sellable for quite some time. I have no idea if they would.
For anyone pointing at VB and saying “Like that”. For some uses VB alone was sufficient but for many others, including me way back when, you bought a huge toolbox of add ons that often cost way more than buying VB itself. Some individual controls were the price of VB. But that marketplace of add-ons was something MS cultivated from the outset and promoted widely. And you just came to understand that this is how things were - VB has some capabilities but when you wanted something much richer you bought a control or other add ons.
Xojo is neither of these at this time.
Its not FM - a database with a programming language built into it.
Nor is it VB with its extremely large market of third parties & add-ons.
no. you can build the tool you need.
I did this entirely in xojo :
I did one, but it’s so tight to my other methods that it is not something I consider selling as a dev tool.
may be I will show them in some future conference.