Start screen too small

How do you control the size and location of the final app window? In the IDE when I start my app the debug window only shows part of my form. I can of course resize it but I’d like to not have to do that for EVERY TIME I run. Also, when I build the same thing happens. I’m slowly working my way through the excellent guides suggested by Tim Parnell and have searched your help system but somehow I haven’t got the handle on what’s going on.

My app is a port of my vb6 chess engine. Yes, I know AlphaZero has no reason to worry; I’d just like to try out some ideas against lower rated programs. There’s a lot of tweaking to be done and I’d like to get to it but so far I’m doing more “why the heck did it do that” type things than actual programming.

Ah, well such is the learning (and unlearning of vb6) process.

Set the size of the window in the Inspector or resize it automatically in the Window Open event.

Positioning of the window can also be controlled in the IDE inspector.
It’s the “Placement” popup menu.

Default                 -    Top Left corner
Parent Window           -   Stagger based on the window that opened this one
Main Screen             -   Centered on Screen(0)  [not recommended]
Parent Window Screen    -   Centered on the same screen as the window that opened this one
Stagger                 -   Stagger based on ?

I prefer and recommend using Parent Window Screen always. It will end up where the user expects it (almost) every time.

I know I’m not communicating this right probably because I’m calling something by the wrong name thus throwing you off.

My app has a form of course and I CAN resize it in the Window Open Event as Dale suggests, what I’m talking about is the size of the floating window that CONTAINS my form: The program starts with my form only partially displayed because my form is bigger than the container window. I can use the form resize thingee on the lower right corner to make everything visible but I would have thought when Xojo lanches my app it would automatically do that for me . In fact, EXACTLY the same thing happens with a build version - my program launches with my form on top of a container form.

Tim: I’m beginning to think that my Lite version of Xojo does not have the same features as the other versions; when I pull up the IDE inspector with my window selected I get the drop down menu you mention by none of the 5 choices makes any difference.

There are only three differences between a Lite license and a Desktop license:

  • You can only build for one platform (the one you select at checkout)
  • Lite does not have access to server-type databases (it’s limited to SQLite)
  • Lite cannot save projects in text format (only .xojo_binary_project)
    None of the framework features are disabled or limited to license type :slight_smile:

You are absolutely correct that the difficulty in communicating your issue lies in your terminology. I would recommend that you stop trying to relate Xojo to the FileMaker paradigm. As you read through the documentation, don’t try to translate it into what you already know. I did this when I first started (translating toward Obj-C) and had complaints about framework features that didn’t work the same (and never would).

The best thing to do is learn how Xojo works as Xojo!

I’m a little confused because most FileMaker users refer to the Window itself as the form (using the FileMaker paradigm), so when you say “window that CONTAINS the form” all I can picture is a Window containing a Window. Which, with a little ingenuity I think might possibly be a ContainerControl on a Window?

The way the designer view works in the IDE is that your app is supposed to look exactly like what you see in the designer. If the Window in the designer isn’t big enough to show all your fields, the built app won’t be either. Make the Window bigger in the IDE, and when it’s displayed in the running program it will open that size.

There are some clever tricks you can do in code with ContainerControls and Windows to implement auto-sizing or view-scrolling effects yourself (they’re not built in to the framework). I’m not trying to dissuade you, but that might be a topic to explore later once you have a better grasp on Xojo as Xojo. I’d be happy to help you with that once you’re that comfortable with the framework.

To get started on this issue, are you able to share with us an example project to show us what your issue currently looks like? A project and even an mockup (doesn’t need to be perfect) of what you’re trying to achieve might help us communicate :slight_smile:

Almost sound like he is trying to make a MDI type app in Windows?
and it is the MDI container that he is referring to … not the “form” window

My suggestion, if this is so, is to ditch the MDI metaphor as it is so 1980’s for one, and pretty much deprecated by everyone including Microsoft

When I turned off MDI everything builds and runs PERFECTLY. But when I ran within the Xojo IDE nothing was showing - turns out that in trying to trace the event cascade I’d put dummy code in each of the event handlers with breakpoints set in each. I took out the break points and every thing seems to be working as I’d hoped. Maybe someday I’ll know enough about Xojo that I can return the favor by helping someone else the way the (many) of you helped me.

I also have to agree that “The best thing to do is learn how Xojo works as Xojo!” Lord knows, learning Xojo as VB hasn’t worked so far!