Platform specific New Window sizing script bug

[Norma_Snockurs]

Hi all, I' ve got a bit of an odd bug that I can't understand why is happening.

This is the script it occurs in but I'm certain that nearly all of the script is irrelevant to the issue:

Allow User Abort [ Off ]
# first make sure it's an admin trying to edit and check all required data exists
If [ Get ( PrivilegeSetName ) = "[Full Access]" ]
 If [ IsEmpty ( Product::ordercode ) or IsEmpty ( Product::cPricebstrd ) or IsEmpty ( Product::ssm ) or IsEmpty ( Product::weight ) or IsEmpty ( Product::stockitem ) ]
   Show Custom Dialog [ Title: "Error!"; Message: "Price Breaks cannot be edited until all denoted fields (*) contain valid data."; Buttons: “OK” ]
   Halt Script
 Else
   # Set up window name
   If [ not IsValid ( QuantityPricing::itemModel ) ]
     Commit Records/Requests [ No dialog ]
   End If
   Set Variable [ $$windowname; Value:"Price Breaks - " & Brand::brand & " " & Product::itemmdl ]
   Set Error Capture [ On ]
   Select Window [ Name: $$windowname; Current file ]
   # Select window for this item in case one is already open, otherwise make a new one.
   If [ Get ( LastError ) = 112 ]
     Set Variable [ $$sourcewindow; Value:Get ( WindowName ) ]
     # Edit price breaks in a new dedicated window
     [color=Red]New Window [ Name: $$windowname; Height: 437; Width: 615; Top: 200; Left: 400 ][/color]
     Show/Hide Status Area [ Lock; Hide ]
     Go to Layout [ “QuantityPricing” (Product) ]
     # Check single unit price band exists. If not, set it up now.
     Perform Script [ “Check for Default Quantity” ]
   End If
 End If
 # Disable closing of window except with scripted buttons.
 Pause/Resume Script [ Indefinitely ]
 Set Field [ Product::grpBandSelect; 1 ]
Else
 Show Custom Dialog [ Title: "Login Error"; Message: "To edit pricing please login as admin"; Buttons: “OK” ]
End If

The script is run from a button on a full screen layout and the idea is that it opens a new small window to allow editing of price-break values. The script functions perfectly every time with one exception. When run on a Mac, the first time after the file is opened in a fresh launch of FileMaker Advanced, the New Window step often fails to resize the window and opens it full screen.

 

I cannot for the life of me understand why this is happening, it even happens with the Script Debugger on. It works fine everytime in plain FileMaker Pro and the same in Windows. If I add a Move/Resize window step immediately after the New Window one and define the same size parameters the problem goes away, though I should not have to do this as the window size has already been specified in the New Window step. There are no other scripts running at all and it is not called from another. One or two variables are used by other scripts.

 

I have tested this in hosted and single user modes and it makes no difference. Tested with FMP 9.0.3, FMPA 9.0.3, OS X.4.8, OS X.4.11, OS X.5.2, OS X.5.3, XP Pro SP2 & SP3 on various hardware (Intel & PPC) , standalone and networks.

 

Any ideas?

[AHunter3]

I have no clue, but what happens if you replace that with

 

New Window

Move/Resize Window [your specs]

 

?

[Norma_Snockurs]

...what happens if you replace that...

Thanks A.H. Well that works every time as I'd expect but the problem with doing it that way is that I then get a window sized at full screen which subsequently resizes to the correct dimensions. It happens slowly enough to be noticeable and is nowhere near as smooth as using the single New Window step which is what I should be using. The Freeze Window step is no help here either as that unfreezes as soon as a new window is opened.

 

I have noticed also that I can get the problem to occur every time if more than one database module is/has been open to start with, so symptoms are pointing towards a possible window drawing bug.

 

I tried disabling all the script steps apart from the New Window one and it still opens full screen although interestingly I then get a flash of the window at the correct size before it goes full screen which suggests something is forcing it to resize back to the database default full screen size after it has sized to the defined parameters.

 

I've gone back over a month of backups until this script didn't exist and the bug exists in the very first version of the file that includes the script and layout.

 

I'm also thinking that it can't be a corrupt file as there are no other problems and it is fine in other versions of the app. and platform. I was hoping someone may have come across this one before as it's repeatable.

[Norma_Snockurs]

I've patched round it for now. Testing for the window dimensions immediately after the New Window step and adjusting size if the window is sized wrong. At least then there is only a flash on the first time the window is opened after the database launches.

 

It seems ridiculous that I have to do this and I keep thinking I must be missing something but it is not a complex issue. The New Window step is straightforward - open a New Window at the defined dimensions. I can see no other factor that would interfere with this and cause the dimensions to be ignored. That I can repeat it even to the point of running just the step on its own and it only happens the first time I run it points toward a FileMaker bug.

 

It seems like though, there may be a specific order of circumstances that bring it about. By creating a new database and new script I can't replicate the bug.

[AHunter3]

I was thinking maybe there was something it did not like about the numerical params being passed, and was handling it by saying "#%^@ that, I'm maximizing this window in lieu of instrux I can deal with!"

 

But if New Window followed by Adjust works just fine it can't be that.

 

Odd.

 

Can you replicate prob in a fresh new file?

[David Head]

Have you tried running specific script steps with the debugger? I would try skipping a few steps and see whether it is having an effect. Specifically, I would try running just:

 

Set Variable [ $$windowname; Value:"Price Breaks - " & Brand::brand & " " & Product::itemmdl ]
New Window [ Name: $$windowname; Height: 437; Width: 615; Top: 200; Left: 400 ]

And see whether that works. If so, it is the other steps that are affecting things.

 

FWIW, you don't need the Set Error Capture [ On ] step.

 

And can I ask what this is for:

Set Variable [ $$sourcewindow; Value:Get ( WindowName ) ]

 

And finally, why are you using global variables?

 

(not that any of the three things above should be affecting anything)

[Norma_Snockurs]

Have you tried running specific script steps with the debugger?

Hello again David. Yes, I have spent some time on this issue including with the debugger. As I have to get on, I have branched round it for now by testing for the correct window size immediately after it is created and forcing a resize if it's wrong.

 

When I have more time I will come back to the problem but I have narrowed it down to something happening as a result of a script running at file open. If I disable that script then the new window is created reliably every time. I'm speculating wildly here but it's possible that it's something to do with the fact that the solution has several modules, the default layout height & width are not hardcoded and are stored as globals in one of the modules (the client frequently changes their mind about layout sizes). Watch this space.

 

I did try just

Set Variable [ $$windowname; Value:"Price Breaks - " & Brand::brand & " " & Product::itemmdl ]
New Window [ Name: $$windowname; Height: 437; Width: 615; Top: 200; Left: 400 ]

and the bug was still there. In fact a one line script comprising of just the New Window step still failed to size the window correctly on the initial call.

 

..you don't need the Set Error Capture [ On ] step.

It seems not, in this context, and of course this makes me realise that I have not fully understood the function of this step. In fact, why would you need this step if, as it appears, the error is 'captured' anyway? If it is to prevent the display of an error dialogue then how do you know which operations would throw up a dialogue and which ones wouldn't? The 'Select Window' step evidently does not but I know of several other operations that would present an error message (e.g. a resultless Find).

Thanks for the heads up. Evidently I still have a lot of reading to do.smiley-undecided

And can I ask what this is for:

Set Variable [ $$sourcewindow; Value:Get ( WindowName ) ]

 

...And finally, why are you using global variables?

Crikey, you are a hard taskmaster aren't you David?smiley-wink It's storing the value of the window name for use in another script of the same file at which time the value of $$windowname would almost certainly be different. Obviously Set Variable [ $$sourcewindow; Value:$$windowname ] would work here also. I think I added the steps containing $$windowname a fair while after the $$sourcewindow one was written. I haven't got around to changing it because it works.

[David Head]

It seems not, in this context, and of course this makes me realise that I have not fully understood the function of this step. In fact, why would you need this step if, as it appears, the error is 'captured' anyway? If it is to prevent the display of an error dialogue then how do you know which operations would throw up a dialogue and which ones wouldn't? The 'Select Window' step evidently does not but I know of several other operations that would present an error message (e.g. a resultless Find).

Thanks for the heads up. Evidently I still have a lot of reading to do.smiley-undecided

You need the Set Error Capture [On] only when you want to suppress a FileMaker error dialog and perhaps replace it with a custom dialog. In this case, since no error dialog is generated, the step is not needed. As you have said, the error is still generated and is available for querying via Get(LastError). I have just had an article published in FileMaker Advisor magazine - Good Catch! Error Capture and Testing in FileMaker Pro Scripts. It may be worth reading smiley-wink

Crikey, you are a hard taskmaster aren't you David?smiley-wink It's storing the value of the window name for use in another script of the same file at which time the value of $$windowname would almost certainly be different. Obviously Set Variable [ $$sourcewindow; Value:$$windowname ] would work here also. I think I added the steps containing $$windowname a fair while after the $$sourcewindow one was written. I haven't got around to changing it because it works.

Not a hard taskmaster but rather an inquisitive soul. smiley-wink I am always interested why people find the need to use global variables. Don't get me wrong - there are valid uses for them. But many people using them will fall into the sort of problem you have here when they are not managed - now you have two global variables that mean the same thing. So which one does the other script look at? See how this can cause difficult troubleshooting problems? Anyhow, something to think about.

[Norma_Snockurs]

I am always interested why people find the need to use global variables.

I find that the difference between local and global script variables marked enough that the two are very different beasts. I think I tend to use global ones more (almost by default) as this used to be the way that a variable would be set-up for use in a script before FileMaker 8 came along. It was always a global field that had to be used. I guess I am just used to this 'global' behaviour.

 

The local script variable has severe limitations as, once the script is halted or branched out of, the value is inaccessible or lost (admittedly this self-clearing behaviour can be useful too). If I use a global script variable then it is often much easier to 'pick up where you left off' running the same script again or even use the value in another script or sub-script.

 

I do also find it a little frustrating that the global script variable isn't truly global, restricted as it is to it's own file. A case where the old global field approach still holds merit.

 

I can see the point you are making about proper management of script variables and surely this would've applied to pre-v8 versions where setting up a global field was the only option?

 

I've written that down smiley-wink

[David Head]

The local script variable has severe limitations as, once the script is halted or branched out of, the value is inaccessible or lost (admittedly this self-clearing behaviour can be useful too). If I use a global script variable then it is often much easier to 'pick up where you left off' running the same script again or even use the value in another script or sub-script.

Not really severe limitations. A local variable can be passed to another script as a parameter and then passed back as a script result. It just takes a little effort to program that. Using global variables instead strikes me as lazy programming. And don't bother shooting me for that comment - I have been shot enough for it but still hold that opinion. There are enough references around in programming texts along the lines that global variables should only be used as a last resort. I subscribe to that view.smiley-laughing

[Norma_Snockurs]

Using global variables instead strikes me as lazy programming. And don't bother shooting me for that comment - I have been shot enough for it but still hold that opinion. There are enough references around in programming texts along the lines that global variables should only be used as a last resort.

I wouldn't criticise an opinion like that David, especially as my own inexperience often leaves me a little disadvantaged in any debate involving best practices. You have good reason to have that view.

 

I shall review extensively the absolute necessities of when and where to use specific variable types in FileMaker. I value your opinion and all others posting here and I find I usually best learn by doing things wrong and then working out or discussing why (although this is not what you want to be telling a client!).

[brsamuel]

Did you try drawing the window off screen first (-5000) and then move it into place? You shouldn't have to, of course, but you would avoid some of the flash.

 

 

samuel

[Norma_Snockurs]

Did you try drawing the window off screen first (-5000) and then move it into place?

Good call Samuel but unfortunately, as the bug involves FileMaker completely ignoring the prescribed window dimensions/positioning on the first pass of the script, that off-screen draw trick sadly doesn't improve matters.

 

When I return to this issue I will update this post as I'm sure I can at least narrow this bug down further.

[Norma_Snockurs]

OK, I spent some more time on this issue and here's what's happening;

 

FileMaker Pro is launched and an Order Database module is opened. (or the Order DB is opened which launches the app.)

 

The Product Database module is accessed by a button in the main Order layout which fires off a nav. script which contains an 'Open File' script step that opens the Product DB.

 

Under 'File Options' there is an 'Open DB' script assigned to run upon opening of the Product DB module. This script does not run at this point, though the Product DB module opens fine. (If the Product DB module is opened directly from the Finder the Open DB script runs as it should.)

 

The user then decides to edit multiple pricing by clicking a button on the Product DB (Product) main layout that runs the script I quoted in post #1. As can be seen, this opens a new window which has the same 'Product' table as it's master. At this point the window displays the same layout as the main product layout from where the button was clicked which is normal FM behaviour. However, after the New Window script step opens a window to the specified size, the next thing that happens is that the 'Open DB' script then runs, despite the fact that the file is already open. This script contains a full screen window sizing step and it is this that is causing the window sizing 'bug'.

 

So what this boils down to is that the script assigned to run at file open is not running at file open but when the first time another, new window is created from within that file.

 

I don't understand this. Is there some aspect of FileMaker's behaviour that I am overlooking here or is this really a genuine bug? I thought that a script assigned to run on file open ran the first time the file was accessed but never after that (unless of course all windows for that file are closed).