Forum Replies Created
-
Posts
-
The example you attached doesn't work. On Vista 32bit there's no main form visible when you run the program.
Set
sFrameBar1.ShowHint := True;
and then do something like this:
sFrameBar1.Items[0].TitleButton.Hint := 'Test';
There must be something else going on in your code because I cannot confirm what you're saying. Reducing the main form's size after maximizing doesn't throw an error here.
Where do you position the tabs of the tabsheet? At the bottom by any chance?
.
'Witcher' wrote:But this property was always case-sensitive. This made for speed-up string works when Third-party list contains many different types.I must have been lucky for years then, because I've never heard of this before and there is no mention of case-sensivity in the help file either (unless I've overlooked it). Thanks for pointing it out, though.
Yes, your test application shows the behaviour I was experiencing. In the meantime, I have found an old solution posted by Peter Below for a related problem:
Quote:
“The main problem seems to be that the scrollbox does not take focus when clicked on, and the MS Intellimouse driver will only send WM_MOUSEWHEEL messages to the control with focus. So the messages go to the form.”
procedure TForm1.FormMouseWheel(Sender: TObject; Shift: TShiftState;
WheelDelta: Integer; MousePos: TPoint; var Handled: Boolean);
begin
if PtInRect(scrollbox1.BoundsRect, ScreenToClient(Mouse.CursorPos)) then
scrollbox1MouseWheel(Sender, Shift, WheelDelta, MousePos, Handled);
end;
procedure TForm1.scrollbox1MouseWheel(Sender: TObject;
Shift: TShiftState; WheelDelta: Integer; MousePos: TPoint;
var Handled: Boolean);
var
msg: Cardinal;
code: Cardinal;
i, n: Integer;
begin
Handled := true;
if ssShift in Shift then
msg := WM_HSCROLL
else
msg := WM_VSCROLL;
if WheelDelta > 0 then
code := SB_LINEUP
else
code := SB_LINEDOWN;
n:= Mouse.WheelScrollLines;
for i:= 1 to n do
scrollbox1.Perform(msg, code, 0);
scrollbox1.Perform(msg, SB_ENDSCROLL, 0);
end;
The above works with a regular scrollbox, but I haven't checked with the sScrollBox. Anyway, I hope this helps others in the future.
Any chance that you can at least adapt the painting of the checkboxes in the TCheckListbox to the skin that is used? I mean, background color and check mark of the checkboxes.
Thanks.
Serge, I finally found out what is causing the AV.
Steps to reproduce:
Open ASkinDemo
Remove PopupMenu1 from the PopupMenu property of MainForm
Recompile
Click on the 'Skin options' tab and then right-click on the button of the SkinsDirectoryEdit
Click 'Insert Unicode control character' -> 'LRM'
Close popup menu
Right-click on the button of SkinsDirectoryEdit again
Access Violation (you will have to kill both Delphi and the demo in the Task Manager afterwards!)
Steps to reproduce:
1. Run test.exe in Debug Mode from the Delphi IDE
2. Click on Button 1
3. Right-click on button of sDirectoryEdit1 on the modal Form2
4. Choose the 'Insert Unicode Control Character' menu item from the popup menu
5. Click on LRM, closing the popup menu
6. Right-click on the button of sDirectoryEdit1 again
7. Crash
Error message: “First chance of exception at $76C4FBAE. EAccessViolation at address FEEEFEEE. Read of address FEEEFEEE.”
Sometimes the whole IDE locks up and I can't kill the running test program anymore – not even through the Windows Task Manager. I have to stop the Delphi process to gain control again.
If you run the test program outside the IDE, you will get the behaviour I've described in post #3.
The PC is a development machine and not hooked up to the web, sorry.
.
I looked further into this and it seems that Photoshop CS5 and TActionMainMenuBar are somewhat incompatible with each other. CS5 not only changes the highlight and other colors of a TActionMainMenuBar (if the colormap is set to something other than the default), but also its predefined font. No matter if AC is used or not. Well, I guess we just have to live with it, although I have no idea how it would be possible for CS5 to change design time settings of a Delphi component.
Serge, the access violation I described in post no.3 is still there in v. 7.43. Can you check? Thanks!
Sorry for the late answer, I missed your post.
No, that is not normal. Actually, when I remove all AlphaControls (including manually removing all references to sSkinManager and sSkinProvider) from the project, I see what you've uploaded as “BeforeCS5.jpg”.
Please find attached a demo project. You have to set Ctl3D := False to reproduce the bug.
While testing, I came across another ununsual behaviour, by the way. Right-click on the button of the sDirectoryEdit, and a pop-up dialog appears (see attachment 1, is this as designed?). Select 'Insert Unicode Control Character -> LRM'. Once you've closed the dialog and right-click on the button again, you'll either end up with an AV (see attachment 2) or a tiny and empty pop-up (see attachment 3). Can you please check? I've attached a compiled version of the demo application as well, as the last two errors I've described only appear randomly (either with the modal form still open, or after closing and reopening it).
Vista Home Premium 32bit (all updates applied), D2007 Pro (all updates applied)
