Hi, Recently I was experimenting using PERFORM-ACTION-OPEN-URL instead of an OpenWindow action to open a Modify window on a specific entry (using the ?eid=<request id> parameter). It's easy enough to use and I certainly got it working, but the performance as compared to OpenWindow was abysmal.
My guess is that this has something to do with browser caching...maybe this method can't use the cache or something. But I'm not sure since I don't really know anything about how browser caching works. I opened up the Network Monitoring console on Netscape and do see some significant differences in the request/response transactions, but I don't quite know how to interpret it. Does anyone have any thoughts or experience as to why I'm seeing this performance difference or how to mitigate it if at all possible? I've tried it on each of IE, Chrome, & Netscape with similar results. FYI here are my reasons for potentially wanting to use PERFORM-ACTION-OPEN-URL: when (in the natural course of navigating through my application) the user wishes to modify some entry, I have some generalized workflow that causes the app to open a Modify window. If the window is opened using OpenWindow, though, and the user subsequently attempts to refresh the browser page, it's converted to a Query (Search) window and the context is lost. Similarly, I was hoping to preserve browser history functionality for the user. If a user navigates from one entry to another (on the same for or a different one), then the browser's Back and Forward functions should work correctly and revisit the appropriate previously visited entries in modify mode, but with OpenWindow they don't. Using PERFORM-ACTION-OPEN-URL accomplishes both of these goals NICELY and I'd switch my generalized workflow to use it except for the performance issue. Any thoughts? Thanks, Charlie _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"