Xojo Developer Conference
25/27th April 2018 in Denver.
MBS Xojo Conference
6/7th September 2018 in Munich, Germany.

one window or two? (Real Studio getting started Mailinglist archive)

Back to the thread list
Previous thread: Help please - JPeg and PDF Drag 'N Drop
Next thread: keeping tabs in a canvas


RB Database   -   tom.russell transport.alstom.com
  one window or two?   -   Joe Cabrera
   Re: one window or two?   -   CV
    Re: one window or two?   -   Lars Jensen
   Re: one window or two?   -   Joe Cabrera
   Re: one window or two?   -   CV

one window or two?
Date: 05.02.06 01:34 (Sat, 4 Feb 2006 19:34:43 -0500)
From: Joe Cabrera
I have a CrosswordClass which I use for making crosswords. Currently
I have one window in which you enter the dimensions of the puzzle,
then press the push button, and that window will go away while a new
one is created with a blank grid to your specified dimensions.

Should I instead be doing all this in _one_ window, just turning
various items invisible/visible as I need them?

I like separate windows because it's just easier dealing with the
window layout that way. Plus I just instantiate the crossword just
the one time this way and everyone's working from the same crossword;
otherwise, wouldn't the first window have to pass the grid size info
to the second (using global variables I guess), so that the second
window could instantiate the crossword with the speciified dimensions?

But if I should keep everything in the same window, is there an
easier way to play with the overlapping layouts? It would be great if
the RB IDE had something like Photoshop layers that I could turn on
and off to visualize things more easily, but I assume that function
isn;t there.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: one window or two?
Date: 05.02.06 18:52 (Sun, 5 Feb 2006 09:52:39 -0800)
From: CV

On Feb 4, 2006, at 4:34 PM, Joe Cabrera wrote:

> I have a CrosswordClass which I use for making crosswords.
> Currently I have one window in which you enter the dimensions of
> the puzzle, then press the push button, and that window will go
> away while a new one is created with a blank grid to your specified
> dimensions.

That sounds like a traditional approach. This window, maybe call it
SetUp, should have some representation of the puzzle itself so that
the casual user understands the parameters that he/she is setting.
For example, a small image showing dimension A, dimension B, etc. You
would also have default settings in place on initial startup, and you
would save the user's last settings in your preferences file and
restore them in subsequent starts.

>
> Should I instead be doing all this in _one_ window, just turning
> various items invisible/visible as I need them?

Why not get the first approach working in all aspects, then assess
whether a one window approach provides a worthwhile benefit.

>
> I like separate windows because it's just easier dealing with the
> window layout that way.

Definitely, and your SetUp window doesn't have to Close. If you wish,
you can keep it open, then hide and show it when appropriate while
maintaining the user's settings in properties.

> Plus I just instantiate the crossword just the one time this way
> and everyone's working from the same crossword; otherwise, wouldn't
> the first window have to pass the grid size info to the second
> (using global variables I guess), so that the second window could
> instantiate the crossword with the speciified dimensions?

I'm unclear what you mean here because I don't know the details of
your approach, so I'll ramble. SetUp will instantiate a new Crossword
instance, and pass the user defined parameters in a constructor or
call an Init method belonging to Crossword. CrossWord will have
properties that accept and hold these parameters, and methods to
implement the puzzle configuration accordingly.

It's likely that CrossWord will enable a menuitem for SetUp when it
opens so that the user can revise the configuration at this point,
probably before providing input into the puzzle.

Your File menu may also have a New Puzzle menu item with a
menuhandler in App. When this is selected you would instantiate a new
Crossword instance, using the current user settings from SetUp.
>
> But if I should keep everything in the same window, is there an
> easier way to play with the overlapping layouts? It would be great
> if the RB IDE had something like Photoshop layers that I could turn
> on and off to visualize things more easily, assume that function
> isn;t there.

You might look at PagePanels.

Best,

Jack

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: one window or two?
Date: 05.02.06 20:02 (Sun, 5 Feb 2006 11:02:24 -0800)
From: Lars Jensen
> But if I should keep everything in the same window, is there an
> easier way to play with the overlapping layouts?

I'm not sure what you mean by "overlapping layouts", but I suggest
that you not worry about the ultimate usability and workflow
implications of 1 vs 2 windows right now. Get it working in the
simplest way you can, and then play with it and see what you think.
One of the great pleasures of working with RB is that it's so easy to
try things, and you can throw them away if you don't like them because
you haven't invested that much time in them.

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: one window or two?
Date: 05.02.06 20:46 (Sun, 5 Feb 2006 14:46:57 -0500)
From: Joe Cabrera
Jack said:

> > Plus I just instantiate the crossword just the one time this way
>> and everyone's working from the same crossword; otherwise, wouldn't
>> the first window have to pass the grid size info to the second
>> (using global variables I guess), so that the second window could
>> instantiate the crossword with the speciified dimensions?
>
>I'm unclear what you mean here because I don't know the details of
>your approach, so I'll ramble. SetUp will instantiate a new Crossword
>instance, and pass the user defined parameters in a constructor or
>call an Init method belonging to Crossword. CrossWord will have
>properties that accept and hold these parameters, and methods to
>implement the puzzle configuration accordingly.
>
>It's likely that CrossWord will enable a menuitem for SetUp when it
>opens so that the user can revise the configuration at this point,
>probably before providing input into the puzzle.
>
>Your File menu may also have a New Puzzle menu item with a
>menuhandler in App. When this is selected you would instantiate a new
>Crossword instance, using the current user settings from SetUp.

You're right that I'm going to want to add a NewPuzzle menu which
will bring up the SetUp window.

I think I'm unclear just where the best place is to instantiate a new
Crossword in my code. Right now it's in the SetUp window code, but
then no other window knows about the created Crossword instance. Do I
subclass Application, and instantiate the Crossword there when it
activates, which I assume makes it available to the entire program?

Is that clear? I'm still new to the RB world so I'm a little fuzzy on
things that may be obvious to y'all...

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: one window or two?
Date: 06.02.06 07:13 (Sun, 5 Feb 2006 22:13:59 -0800)
From: CV

On Feb 5, 2006, at 11:46 AM, Joe Cabrera wrote:

> Jack said:
>
>> > Plus I just instantiate the crossword just the one time this way
>>
>>> and everyone's working from the same crossword; otherwise,
>>> wouldn't the first window have to pass the grid size info to the
>>> second (using global variables I guess), so that the second
>>> window could instantiate the crossword with the speciified
>>> dimensions?
>>>
>> I'm unclear what you mean here because I don't know the details of
>> your approach, so I'll ramble. SetUp will instantiate a new
>> Crossword instance, and pass the user defined parameters in a
>> constructor or call an Init method belonging to Crossword.
>> CrossWord will have properties that accept and hold these
>> parameters, and methods to implement the puzzle configuration
>> accordingly.
>>
>> It's likely that CrossWord will enable a menuitem for SetUp when
>> it opens so that the user can revise the configuration at this
>> point, probably before providing input into the puzzle.
>>
>> Your File menu may also have a New Puzzle menu item with a
>> menuhandler in App. When this is selected you would instantiate a new
>> Crossword instance, using the current user settings from SetUp.
>>
> You're right that I'm going to want to add a NewPuzzle menu which
> will bring up the SetUp window.

>
> I think I'm unclear just where the best place is to instantiate a
> new Crossword in my code. Right now it's in the SetUp window code,
> but then no other window knows about the created Crossword
> instance. Do I subclass Application, and instantiate the Crossword
> there when it activates, which I assume makes it available to the
> entire program?

You probably want to add a menuitem under File and name it New
Puzzle. Add a menuhandler for FileNewPuzzle in App. Now you have some
design choices. When the user selects File/New Puzzle, decide whether
you want to open CrossWord with default settings(based on user's last
configuration selections) or do you want to show SetUp first and then
show CrossWord when the user dispatches SetUp. Probably the former,
right? Think of it like opening a new document in Word. You want to
see a blank page that you can start typing into.

Your SetUp window should also be available from the menubar, so that
the opening configuration can be revised per the user's desires. In
this case, the menuhandler for SetUp will go into CrossWord's
menuhandlers, because CrossWord has a method which reads SetUp's
properties and configures itself accordingly.

In the App Open event you can instantiate SetUp and an initial
CrossWord instance. Eventually you may want to have a Preference file
to hold settings on shutdown, and you would read it here. That get's
things going on startup.

>
> Is that clear? I'm still new to the RB world so I'm a little fuzzy
> on things that may be obvious to y'all...

The best thing to do at this point is to 'dummy it up' , maybe just
using blank versions of the windows with titles and pushbuttons until
you're comfortable with the flow and menuing, and the methods needed
to transfer information.

Best regards,

Jack


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>