Suggestions on instantiating a form

Getting Started
1

I have a window that is used for adding records and then doing a calculation when the record is saved. I’ve created a conversion routine to bring in data from an older version of the application and it instantiates the window and the populates it with data and then calls methods in the window to save it, which causes the data to be calculated.

The problem is when it is completely done converting the data, the window popups up with nothing in it and it is sitting on top of the window that calls the conversion routine.

When I instantiate the window, I’m changing it to hidden so it doesn’t show being populated. At the end of the routine, I’m issuing a window.close to close it but it continues to popup up.

Any suggestions to remedy this.

BTW, I have to use the window because all the calculation methods are in the window and moving these to a module would be very difficult.

2

in general, if you have such a window, you can often treat it like a class as long as it doesnt do things to show itself in the Open event.

For example, a window with a public method of CalculateArea(w as integer, h as integer)
can be used in this manner:

dim mywin as new  calcwindow
//note.. no call to show or showmodal

dim a as integer = mywin.CalculateArea(2,5)
mywin.close
mywin = nil

But if your open event includes a .refresh, or a .show, then the window might make itself visible.

Another possibility is that you have ‘implicit instantiation’ set to True

If that is the case, look at this code:

dim mywin as new  calcwindow
//note.. no call to show or showmodal

dim a as integer = mywin.CalculateArea(2,5)
CalculateArea.close

That CalculateArea.close will actually cause a second copy of the window to be created!

3

Still trying to figure this out.

The Window is not a class and I’ve tried making a copy of it and turning implicit installation OFF and it still shows up after processing using it.

Would it make a difference that it’s being instantiated in a window that is a document window?

There’s nothing in the open event. Even if I just do:

wHome (this is the main window with the main toolbar on it)

if UpdateLoans then

'— CALLS A METHOD IN A MODULE TO DO THE FOLLOWING
var wAmort2 As New Amort
… populate form with data needed to calculate and then ( I commented all this for testing)
wAmort2 = nil

end

'— WHEN IT RETURNS FROM THE MODULE THE WINDOW POPUPS UP

4

The Window is not a class

But you can treat it like one. You can create new objects of the the type, for example

turning implicit installation OFF and it still shows up after processing using it.

Sounds like you are accessing something visible after /during the close event, maybe?

Would it make a difference that it’s being instantiated in a window that is a document window?

No

wHome (this is the main window with the main toolbar on it)

Is that important? Doesn’t look like a line of code
.
.

Do these 3 lines cause a window of type Amort to appear?

var wAmort2 As New Amort
wAmort2.close
wamort2  = nil

Is Amort set to be the default window of your app?
Is there any code in the Close() event of Amort?

5

Did you set the window’s Visible property to false in the IDE?

6

You mean after using it and then hiding it? We had this recently (I had the problem too). If you access any property of the window while it is hidden, you’ll make it visible.

7

That shouldn’t happen unless you’re using implicit instantiation.

1 Like
8

It can happen if you access any control on the window
So for example, if you have a listbox and you access mylist.list(mylist.listindex)
To avoid that , create a global property on the window

var listresult as string

then set listresult = (some value from a control) as the controls are used while the window is visible

You can safely access listresult from a non-visible window without making it become visible again.

9

Yar, sorry. My excuse is I was on a train at 80mph and it was around midnight.

1 Like
10

This is not true. Example Project

The auto-visible behavior only happens with Implicit Instance.

Edit: Maybe I misunderstood what you were saying? The correct way to go about all of this is to turn implicit instance off.

11

I have never used implicit instance, and I have seen this happen.
Whether it is , (or was) a bug, I don’t know, but it has happened to me.

OP says ’ I’ve tried… turning implicit installation OFF ’

Although I agree with you… everything about this post shouts implicit instantiation to me, also…

12

The OP would have to turn implicit instance off on every single window in the project. It isn’t enough to turn it off on the main window. Every window you add to a project has implicit instance True by default.

1 Like
13

For those who don’t know, you can change the default by following this:
https://documentation.xojo.com/topics/advanced_features/setting_default_values_for_xojo_framework_class_properties.html
and adding ImplicitInstance=False or ImplicitInstance=Off to your Window.defaults (or DesktopWindow.defaults) file.

3 Likes
14

Some addition information I can add as the OP:

We are using a Window class as our default for all windows and so turning off Implicit Instance in the Window probably doesn’t do any good and, in fact, did not seem to make any difference.

I’m suspecting that there may be something in our class that is causing this to happen, but we did find a suitable workaround. When processing is completed, we run this close to close any open instances of the window.

for x as Integer = WindowCount DownTo 0
if Window(x) isa wAmort then
Window(x).Close
end
next

15

Turning it off in the superclass doesn’t affect the windows derived from it. Your workaround is classic implicit instance code.