I have what is likely a naive question. If there could be such a solution where a pointer to a theme property could be established, why couldn't loading a new theme just generate the same id as the one being reloaded? In other words, if I have a theme object foo, it gets generated a handle, right? If I load a new theme, if the new theme has an object foo, why can't it get assigned the same handle? If this were possible, it wouldn't have any performance penalties, and still make the client-side easier to program.
There is a potential resource leak, but if the same code that loaded the new object also freed the one it was replacing, this would work. How is the general case handled when two theme files are loaded and they both specify the same property? In other words, panel is described in two theme files, and they are both loaded at the same time? I notice that if I set a theme property to one of the default objects, say "panelbar", when the theme is reloaded it is re-displayed correctly. It's only with custom objects, that a propblem seems to arise. But with custom theme objects they are associated by name. Coudln't pgserver reload these properly based on the name of a new theme object replacing it? On Mon, 2002-06-10 at 23:46, Micah Dowty wrote: > > This is a problem that Eric Christianson and I were discussing, and I came > up with a few solutions, but I thought the rest of this list might want to > have a say in it (And this sounds like the kind of problem Yann might like ;) > > When a theme is loaded or unloaded, pgserver has code to handle redoing > theme lookups where necessary. Apps however don't have a chance to do this. > Therefore, any handles the app has that were owned by the removed theme > become invalid. > > The most obvious solution to this is to have pgserver send an event to all > apps when a theme is loaded or unloaded. This would be necessary for > non-handle properties looked up from themes. > > Another option that may be implemented concurrently with the event solution > is to create a new type of handle that specifies a theme object and > property. This handle, when dereferenced, would automatically do a theme > lookup and additional dereference. It would effectively be a pointer to a > theme property with a pointer to a pointer :) > > Anyway, this new type of handle would be less efficient per-use but more > efficient per theme reload. It would never become out of date with respect > to the loaded themes. > > -- > Only you can prevent creeping featurism! > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - >http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
