Data browser updating during all-at-once fit

I'm repeatedly calling a function which does All-At-Once fits, and every time I do the AAO fit the Data Browser updates with the temporary fit waves. So I call prepare_to_fit(), which calls do_many_fits(), which does FuncFit /N/W=2 [...] as described in the manual on page 701.

When I call do_many_fits(), the data browser doesn't update. But when I call prepare_to_fit(), the data browser updates repeatedly with the temporary waves created during the all-at-once fits.

So (1) can't these waves be made 'free'? and (2) can I freeze the data browser updates without the kililng and reopening it (annoying, because it is then the top window)?
If the data is stored in a data folder named "test" this might help a little:
modifybrowser collapse=getbrowserline("root:test")
Print "Long routine here..."
modifybrowser expand=getbrowserline("root:test")


Is there a way to minimize (and restore) the browser window from code?
HJ

PS: It needs to be passed to "Execute" in functions...
HJDrescher wrote:
If the data is stored in a data folder named "test" this might help a little:


That is correct. However, the Data Browser will get events that it would attempt to handle even when your function is running. In time critical applications closing the Data Browser is the best choice.

Quote:
Is there a way to minimize (and restore) the browser window from code?

You can use:
CreateBrowser
ModifyBrowser Close


This is not really minimizing but has the same effect.

A.G.
WaveMetrics, Inc.
I am aware of the execute "modifybrowser close" option (although I try to avoid execute).
However, restoring the DB is not really easy after the close operation and a program package permanently killing the data browser might drive users insane.

Would "better" control over the DB be something for Igor 7 ?

Back to topic: I am usually working with free coefficient waves and I think (not tested) creation of the temporary waves (actually they are useful for checkup) as free wave before calling funcfit should work the same way.

HJ
HJDrescher wrote:
However, restoring the DB is not really easy after the close operation and a program package permanently killing the data browser might drive users insane.

If you set the Data Browser to remember its position etc., there is no reason you would have a problem restoring it unless you are attempting to restore a Browser window on a screen that is no longer available for IGOR.
Quote:
Would "better" control over the DB be something for Igor 7 ?

The Data Browser in IP7 is part of the application with lots of new bells and whistles.

A.G.
WaveMetrics, Inc.
Is it possible to do set this behavior by code?
On my machine (Win7, IP6.37) the data folder are collapsed after reopening and I have to travel through the data structure again...
HJ
Quote:
Is it possible to do set this behavior by code?

The only way to retain the folder representation is using:
ModifyBrowser saveExpandedFolders
Unless you have a very specific reason to do this you might be better off using "find" on a particular data object name that you want to be visible, e.g.,
ModifyBrowser find="yourObjName"


A.G.
WaveMetrics, Inc.
That would be the "not easy" option.
I'll stick to the collapse / expand version and wait for IP7 ;-)
HJ
HJDrescher wrote:
That would be the "not easy" option.
I'll stick to the collapse / expand version and wait for IP7 ;-)
HJ

I don't believe that the Igor 7 Data Browser has any substantial changes with regards to the functionality you are requesting. Though you won't need to use the Execute operation any more, since it's built in.

The update mechanism is somewhat different than the Igor 6 DB, so you may find that the Igor 7 DB performs better or worse in this particular aspect.
I've been forcing the browser to close (as mentioned in the first reply to this post) but I have the same problem as HJDrescher:

HJDrescher wrote:
Is it possible to do set this behavior by code?
On my machine (Win7, IP6.37) the data folder are collapsed after reopening and I have to travel through the data structure again...
HJ


So if I can request something for Igor 7, I would request a "DelayUpdate" for the data browser. Or, perhaps easier but too specific, /FREE waves being used during an All-At-Once fit.
jcor wrote:
So if I can request something for Igor 7, I would request a "DelayUpdate" for the data browser. Or, perhaps easier but too specific, /FREE waves being used during an All-At-Once fit.

It actually worked that way in the beginning. Actually, they weren't really *free* waves, because free waves didn't exist then, but they were an unnamed precursor to free waves. But enough people tried to find the names of the waves in order to do skanky manipulations (our customers are remarkably creative) that I made them ordinary waves with monstrous names. See, when they weren't able to get a name, they called us for tech support. When you get lots of calls like that, you do something about it. In this case it was to make those waves regular waves.

On the other hand, really the kinds of things people were doing shouldn't be done. Perhaps I need to be more creative in detecting and disallowing dangerous behavior, but that seems like WaveMetrics Nanny State.

John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
Well I started to be creative and I am hacking the hook-function controlling the minimize event.
I think we all just desire
ModifyBrowser MinimizeWin
ModifyBrowser RestoreWin
ModifyBrowser MaximizeWin

simulating user clicks on the three corresponding buttons.
"Maximize" only for completeness.
HJ
HJDrescher wrote:
Well I started to be creative and I am hacking the hook-function controlling the minimize event.
I think we all just desire
ModifyBrowser MinimizeWin
ModifyBrowser RestoreWin
ModifyBrowser MaximizeWin

simulating user clicks on the three corresponding buttons.
"Maximize" only for completeness.
HJ

With the Igor 7 DB at least (and probably also the Igor 6 DB), minimizing the DB won't stop it from updating its representation of Igor's global objects (though it might stop updating of the graph or image of a selected wave displayed in the plot panel).

If you can send an example experiment to support@wavemetrics.com that I can run myself and which demonstrates the problematic updates you are seeing, I can see what happens using Igor 7 and see if there are any changes I can make to improve the Data Browser's performance in the situation.
A sample experiment is about 60MB and requires a lot of code (and I cannot crop much without generating a lot of errors)...
Some run times with identical data (Exp0042LT):
a) Data browser with expanded data folders: 51.5297 s; 53.977 s; 53.5698 s
b) Data browser with collapsed data folders: 18.2537 s; 18.3133 s, 18.2515 s
c) Data browser with expanded data folders minimized: 29.6672 s; 30.217 s; 29.6042 s
d) Data browser with collapsed data folders minimized: 15.9292 s; 16.0841 s; 15.8868 s
e) Data browser closed: 15.102 s; 14.3829 s; 15.086 s

The run times (mstimer) are consistent. Minimizing the tree structure ("NAC") seems to provide the largest improvement. Result c) is surprising. Although the DB is minimized it still updates and costs a lot of time.

You want to see if the fits (3000 in this case) are particularly bad in some range (Wave ChiSq -- marked blue). Yes I could graph them automatically, but I don't want to; there are enough graphs already :-) (and one needs this only in case the result looks "suspicious")

HJ
HJDrescher wrote:
Result c) is surprising. Although the DB is minimized it still updates and costs a lot of time.


Not so surprising. The DB in IP6.x is an XOP. As such it performs its work when it gets idle time from IGOR. As long as the DB window exists (even minimized) it gets its idle messages which give it an opportunity to update its internal structures. If you want it to become dormant you need to close the DB window as I said before.

A.G.
WaveMetrics, Inc.
HJDrescher wrote:
A sample experiment is about 60MB and requires a lot of code (and I cannot crop much without generating a lot of errors)...

If you email me at support@wavemetrics.com, I'll send you information on how to upload to our FTP server, if you're interested in doing so.

I did a few tests using Igor 7 and as far as I can tell, nothing in the DB updates while a user function is running. The DB will update once functions stop running, so if you have a lot of data or are displaying large waves in the plot panel, it may still be worthwhile to close the DB. However for cases in which there are lots of waves created/modified while a function is running and then killed before everything is finished, the Igor 7 DB shouldn't update and therefore the performance should be improved compared to Igor 6.
I'll will get something together tomorrow and I would be happy if you could have a look.
Thanks a lot,
HJ
Igor wrote:

Not so surprising.

I would have expected it to be similar to the run time with the collapsed structure. However, if the internal events are dependent on the expanded folders / visible objects, it is not that surprising.
HJ