On Fri, Sep 17, 2010 at 1:38 PM, tekne <te...@gruppoparentesi.it> wrote: > >> For me this exclude RAM problems so no need to check the RAM. > Yes, I'm sure. I see a lot of physical memory available during and after > startup.
Here, I thought to the physical integrity of the memory, not the memory allowed by Seven to your app. Sometimes a memory card may be defective and induce unexpected effect. >>> As I say to Jacqueline that has managed tech support ticket, in one PC I >>> have tried to defragment the HD and to update the video drivers but the >>> lunch time is always over 60 seconds. >>> I can't try any code because the problem is related to the time to open the >>> first cd of the rev mainstack, and I have no code activated before. >> >> Have you try to run your app after changing its compatibility mode. >> Follow this link. >> http://www.sevenforums.com/tutorials/316-compatibility-mode.html >> >> Could interesting to launch progressively your app with different >> compatibility modes and compare the result: >> - 1) with XP >> - 2) Vista >> - 3) Seven service pack 1 >> - 4) Seven service pack 2 > > Yes, but no news > > Thanks for your support > Riccardo Another test could be to explode your project and test one by one each stacks as a standalone. Start by testing the larger stacks and check the time for each one. Several ideas: - one or more of your stacks needs optimization (see properties like alwaysbuffer, dontuseQT we have proposed above) - A stack or an object in a stack maybe corrupted and this corruption affects only Seven. - All the stacks associated in the standalone are too large to be buffered quickly by rev in Seven. And we can consider this behavior as a bug. Regards, -- -Zryip TheSlug- wish you the best! 8) http://www.aslugontheroad.co.cc _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution