Forum Replies Created
-
Posts
-
I think there is more to it. I have removed the Application.ProcessMessages and the OnPaint event. Now, many times, when I start the application it does not show the initial screen and appears to be hanging (at least in the debugger of the Delphi development environment). Only a process reset and restart will fix it, albeit a few restarts may be needed.
Debugging reveals the application is looping in the windows message retrieval loop. In other words: some needed message has not arrived.
I consider this a serious bug
QUOTE (Pontus @ Jan 22 2010, 07:00 PM) <{POST_SNAPBACK}>Perhaps we (the users of AC) should put together test cases (applications) that can be used to ensure certain functionality. In my case I would put together an MDI test app that ensures that the expected functionality works ok. Then the devlopers of AC can run these apps and check that nothing is broken in the new release.I'm sure Serge (who is the developer of AC) has an extensive test set that he runs before releasing a new version. But we may be able to help him with specifiic test cases, indeed
This is another example why one should never ever use Application.ProcessMessages. You absolutely loose control over all your visual elements and anything can happen. We've learned this the hard way.
Let's look at an example from AC6.53:
Lines 2141 and 2142 of acDials.pas read:
Application.ProcessMessages;
SystemMenu.UpdateItems;Are you sure the SystemMenu.UpdateItems will go right? Isn't there anything the user can have done in the past, that surfaces because of the Application.ProcessMessages and now will invalidate the System Menu? Or make it impossible to do UpdateItems correctly?
That's why we never ever use Application.ProcessMessages.
Unfortunately AC contains 9 instances of this statement.
This problem has more ramifications: if during the paint event, a dialog is created, that dialog is not shown
QUOTE (Support @ Dec 23 2009, 12:14 PM) <{POST_SNAPBACK}>Changing of this array of properties is not forbidden. But you must remember that all properties will be reloaded after the skin changing.
I can make a demo for dynamic changing of properties in the CommonSections property, but time is needed for it. Write me if you need this demo.Maybe it is time to start considering a more universal, implementation hiding procedure to change skin properties dynamically. Could be a very nice addition to AlphaControls.
QUOTE (Wanderlan @ Dec 10 2009, 12:36 PM) <{POST_SNAPBACK}>QUOTE
finden Sie hier: das gleiche Problem mit dem Quick-Fix –http://www.alphaskins.com/forum/index.php?showtopic=4891 [/ url]
Danke — habs auch so gelöst 🙂
leider ist die V6.52 nicht zu gebrauchen Fenster mit fsStayonTop verschwinden usw…
also downgrade
Anderl
Please, keep the forum in English. So everybody can benefit. That's its purpose.
If dialogs go back to the standard font, I wouldn't be very happy
QUOTE (Support @ Nov 17 2009, 12:13 PM) <{POST_SNAPBACK}>But maybe one global property will be more handy for developer?I simply hate globals: in the end they always end up becoming non-global.
QUOTE (Support @ Nov 17 2009, 12:13 PM) <{POST_SNAPBACK}>What about first two problems?” border=”0″ alt=”smile.gif” /><!--QuoteEnd--></div>
<p><!--QuoteEEnd-->Problem was solved wasn't it <img decoding=)
QUOTE (Support @ Nov 16 2009, 10:19 AM) <{POST_SNAPBACK}>I must say that question is not easy..If it's that much trouble, I wouldn't bother.
QUOTE (Support @ Nov 9 2009, 10:13 AM) <{POST_SNAPBACK}>Maybe to make a global object CustomTitleFont : TFont = nil and check this object.I also think, putting it in SkinProvider as a published property is a better solution
QUOTE (Pedro-Juan @ Oct 16 2009, 09:55 PM) <{POST_SNAPBACK}>The SkinSection property of sPanel control was WEBBUTTON. When I changed the property to PANEL, the control sGauge worked well.That should not make any difference imo.
QUOTE (Jeffijoe @ Sep 13 2009, 02:25 PM) <{POST_SNAPBACK}>I was wondering, in the Alpha Lite package, will the application only be skinned on my computer, or on the end users?
Because I made a skinned app, and took it with me to my sisters house, and when I ran it there, it wasnt skinned. I made it on Vista, and she has XP. I tried with other PC's too, only
XP though. I had an XP once, with Bricopack, which gives the Vista looks, and it worked there.Either you didn't include the skins at run time, or the skin directory is not stored on the XP computer (that's my guess anyway
)Hello
You can check also your inbox, a letter with other solution was sent there. Maybe this solution will be more universal.By publishing solutions here in the forum, the forum is more useful. So, can you do that? <img src="style_emoticons//unsure.gif” style=”vertical-align:middle” emoid=”:???:” border=”0″ alt=”unsure.gif” />
