Frameset Lesson Learned

I’m not sure if anyone here has dealt with this frustration or not, but I ran into a problem with dynamic loading of framesets when an application I’m writing was loaded. Essentially, the idea was to launch a different frameset to different user types based on user roles when the database was launched. I built the framesets, pages and views, and built the code in the database script PostOpen event to open the correct frameset when the database loaded. The problem was, the PostOpen event occurs only AFTER the database is loaded and whatever the default launch properties of the database happen to be happens before my dynamic frameset loads and what the user gets is either two framesets, or whatever they were working on last session in addition to the right frameset.

After spending way too much time trying to figure it out, it occurred to me to set up a sacrificial frameset which opens a sacrificial view. In that sacrificial view, I’ve set the PostOpen event to essentially close the view. I then make that frameset the default launch property of the application. This has the fortunate effect of closing out the sacrificial frameset.

BUT…why on earth should I have to do such a ridiculous thing? Why isn’t there a QueryOpen property of the database script object which would let me replace the object launched by the DB by default with the object I want it to launch? I just don’t like the idea of deliberately building nonsensical workarounds like this.

Subject: Frameset Lesson Learned

For anyone else who might be looking to do something like this, just look at using Computed Content in your framesets. A frame can show a certain page, view, another frameset, etc, depending on the Userroles.

Subject: RE: Frameset Lesson Learned

Computed frameset might work , but what is your other frameset that you want to open looks or sizes is differnt, then that will not work