Forum Replies Created
-
AuthorPosts
-
HamiltonParticipant
Hi,
The attached file replaces the file of the same name in my previous post.
* To get the scroll bar skinned you need to go into the SkinManager and add TacCategoryPanelGroup to the ThirdParty list with type ScrollControl. There is probably a nicer way of doing this by registering the control in code, hopefully someone can suggest how this is done.
* I fixed the issue with the chevron hot color by using either GetHighLightFontColor(False), GetActiveEditFontColor or GetActiveEditColor to contrast GetHighLightFontColor(True) which is the default color for the header and chevron. I checked with all skins and it seems that the color combinations do not clash but ideally you'd want a color that guaranteed a contrast. If anyone has suggestions how this might be more safely implemented I'll look into that, but for now this works.
So where does that leave us? If you register the aceCategoryPanelGroup control in acExtras or another package and add TacCategoryPanelGroup as a third party skinned control then you should have a control that will be automatically skinned without requiring any code on your forms. This may also form a useful template for other VCL and third party controls that need a skinned appearance without requiring a full implementation (which would have gradients, fancy borders, mouse and other animation effects, etc)
Regards,
Hamilton
HamiltonParticipantHi Serge,
I replaced the TsListView in my commercial app with a DevExpress grid and due to a glitch in our repository I don't currently have access to the old code that demonstrated the fault. This is a bit of a nuisance because it means the form that could consistently demonstrate this fault is no longer available. I tried to repro in my own app and couldn't; however using your app I did show a similar issue (see attached). I couldn't run the exe in your zip, the item appeared in the task bar but the window did not appear. I removed the TnT reference from your code and recompiled in Delphi 2010 to produce the attached image. It is not easy to repro but doing a combination of changing grid widths and quickly dragging the horizontal scroll bar I did twice get the text ghosting and many more times produced the column vertical line glitch. It may be that the column glitch is actual a separate problem caused by the column resizing as that is not something I was doing to produce the issue previously. Sorry I cannot be more clear than that at this stage, all I did was resize the second column to make it much larger than the screen then dragged the scroll bar back and forth and sometimes bad things happened.
The glitch is not easy to repro and I'm not currently using a ListView in any app so getting a fix is a very low priority for me.
Regards,
Hamilton
HamiltonParticipantHi Serge,
Please refer to the attached demo program. The demo shows two list views – the top one is TsListView with the Golden skin, the lower one is an unskinned TListView. Some issues you might notice:
1. Select the first row in the top grid. Then click in the edit to give it focus. Mouseover the top grid and notice the second row goes bold in all columns except the first one. The first row doesn't go bold. The TListView is there as a control – it shows that the VCL control doesn't make the selected row bold in any circumstance.
2. In the code, remove the code from the CustomDrawItem and CustomDrawSubItem procedures, save to remove the declaration and recompile. You'll now notice that the TsListView makes the selected row bold in all columns except the first one.
I was consistently getting a combination of issues #1 and #2 above right up until the point where I attached the code – then I went to check something to write this thread and it didn't happen any more. I have no idea why and no time to work it out right now, but basically I was getting the bold row at the same time as having the colored rows.
Another thing I noticed intermittently was that fast mouse-over movements when the grid had focus sometimes caused the row to be bold (as opposed to issue #1 above where it happens consistently when the edit control has focus).
HTH
Regards,
Hamilton
HamiltonParticipantAnd fixed, cheers Sascha.
LOL some ppl like crosswords, I prefer dev forums 😛
September 13, 2012 at 1:59 am in reply to: No skin on Modal Form but locks Parent Form when closed #48944HamiltonParticipantHi Serge,
Can you explain to me how the form tag should work in this case? If I put a skin manager and provider on a form and set the form tag to -98 then the form is always skinned. Is this what you would expect?
I had previously thought that the -98 tag worked on all controls but I reread your post in thread 7111 and realized that you had stated it only works with standard (non AC) controls. Now that I understand that I can see it works as expected with controls; if I put a TButton on the same form, add TButton to the 3rd party list and then set it's tag to -98 then the button is not skinned but if I do the same thing with a TsButton it is still skinned, which is fine.
Regards,
Hamilton
HamiltonParticipantHi Serge,
Nice demo 🙂
I wrote a little class to handle the skinning, see code below. It needs a couple of improvements that I'm hoping you can help me with. If we can get it working properly you're welcome to use the code in acExtras if you think it might be useful to other ppl. It shouldn't be too hard to get this working properly and then it will be a useful template for ppl that are trying to get other non-standard controls skinned quickly (like the Jv controls that ppl have asked about recently for instance).
For anyone new to this thread pls not the code is just setting colors on the control – there is no manual painting and thus no nice gradients, borders etc that you would expect with a fully skinned control but it is sufficient to create a control that doesn't look out-of-place in a skinned app.
I've attached 2 separate files:
1. aceCategoryPanelGroup should be added to ACExtra to be registered.
2. Once aceCategoryPanelGroup is registered, the demo can be run to test the issues below.
Issues:
1. The scroll bar isn't skinned and I was wondering if you could tell me if there is a message I can send to make that happen? In other words, I think there should be a windows message or command that can be called in WndProc when WM_PAINT is received to tell the scrollbar to be skinned (but I don't know what that command is). I don't think it will be necessary to register TacCategoryPanelGroup as you have done in the demo with TCategoryPanelGroup but this would fix the problem if there isn't a better implementation.
2. The chevron hot tracking does not work consistently. I think there may be a message other than WM_PAINT I need to capture but I'm not sure why! To repro, in the demo if you see the TCategoryPanelGroup that is not skinned (the middle one) I've made the chevron red when it is hot tracked. For this component, if you put the mouse over one of the top header and just click repeatedly then you'll notice that the chevron stays red. In contrast, the TacCategoryPanelGroup component loses the hot track color every second time the panel is collapsed then expanded and doesn't come back until it is expanded the next time (just keep clicking you'll see the hot track color comes and goes). I'm not sure why it doesn't just 'work' after the chevron hot color is set. There isn't a message sent for expansion/collapsing a panel so it may be something caused by the way I'm handling WM_PAINT?
NOTE: The demo you created doesn't have hot tracking so you won't see this in the leftmost CategoryPanelGroup in the new demo because that is included to show the comparison with the old code.
3. I had to workaround the font colors somewhat to achieve chevron hot tracking. The code I used is compatible with the current skins but may cause the chevron to be poorly coloured in future skins. I don't believe this is going to be much of an issue but I'm mentioning it so ppl are aware of it. At the core of the problem, most skins have the same colour for the HighlightFontColor regardless of whether the control has focus, so in order to show hot tracking I used the ActiveEditColor when the focus color was the same. The panel header uses the HightlightColor in the background so it seems likely that ActiveEditColor will always contrast against that (as indeed all skins do currently), but there is no guarantee because they are not a matched pair of colors.
Regards,
Hamilton
HamiltonParticipantThanks Serge that is perfect, cheers! The CommonSections markup looks OK and whereas I don't know the full extent of what is possible with this property, the transparency setting you added is straightforward and simple to replicate. Thanks again – nice timing too, I was about to code a workaround in the next day or two and now I won't have to!
PS For anyone wanting to try the demo, note that the internal skin set in the project is not contained in the project so you'll probably have to change the skin path, set the current skin and set the active flag on the SkinManager for the demo to work.
HamiltonParticipantIssue still exists in 7.69.
HamiltonParticipantFixed in 7.69. However, I noticed you have made font for the selected row bold for all columns except the first one – I suspect this may be an oversight not to include the first column?
Regards,
Hamilton
HamiltonParticipantHi John,
Where is the smooth property you mention?
I just created a test app with a button and a scrollbox; the button creates another button on the scrollbox with a left and top position that places the button off the screen and makes the control scrollable – it works fine.
You say the problem exists when you use TScrollBox – surely that indicates the problem is in your code then not in the TsScrollBox? Apologies if I've misunderstood. If you can post any code I'll help you debug.
Regards,
Hamilton
HamiltonParticipantHi Beherit,
If I put a TsMaskEdit and a TsEdit on a form then I can type text in the mask edit and then press CTRL-C to copy and CTRL-V to paste into the edit, and it works fine. Does that work for you? Is it the particular mask that you are using that is causing the problem?
Regards,
Hamilton
September 4, 2012 at 3:41 am in reply to: No skin on Modal Form but locks Parent Form when closed #48855HamiltonParticipantMy pleasure Milli, glad I could be of help 🙂
Serge: can you repro the issue with the -98 flag?
Regards,
Hamilton
HamiltonParticipantHi Beherit,
Can you explain your problem more clearly? The code below works fine for me, though I'm not sure what you mean by 'copying hex value' so I'm not sure if I tested the right thing.
sColorDialog1.Color := $00FFFFAA;
if sColorDialog1.Execute then
self.Color := sColorDialog1.Color
You may have a string to hex conversion issue and need to look more closely at the value returned by your mask edit.
Regards,
Hamilton
HamiltonParticipantHi,
The PaintItem demo shows how to skin a region, you'll just need to hook the drawing into the right event
http://www.alphaskins.com/ademos.php
Also, is your DB grid being skinned? If it is not then you should enable 3rd party controls through the skin manager and make sure TDBGrid (case sensitive) is in the list of supported controls.
Regards,
Hamilton
August 27, 2012 at 4:08 am in reply to: No skin on Modal Form but locks Parent Form when closed #48840HamiltonParticipantThe alternative fix suggested in thread [topic='7111']7111[/topic] is:
* change the sSkinManager1.SkinningRules.srStdForms property to False.
* place a TsSkinProvider component on each form which should be skinned.
August 27, 2012 at 3:57 am in reply to: No skin on Modal Form but locks Parent Form when closed #48839HamiltonParticipantHi Milli,
I cannot repro this fault using AC768 in Delphi 2010. I set up a sample app as you suggested and it worked fine – but I have huge reservations about the way you've implemented this and aren't surprised that there might be issues because the flow control you've setup is telling the SkinManager to skin Form2 just as it is being closed – which should probably work in theory but is courting problems because it will just take one control with incorrect state flags to cause an AV, and also because it will cause the main form to be non skinned which is not what you intend from what I understand.
I think the recommended approach is to set the form tag to -98. However, I just tested this also and it doesn't work for me. If I set the tag for Form2 to -98 then it and it's controls are still skinned. Ideally this would be fixed.
Serge: can you look into this please? The -98 tag doesn't seem to turn off skinning for a form OR control, at least not as I've understood it should work from your post [topic='7111']7111[/topic]
What I think you should perhaps try is to move the SkinManager control logic off the sub form and onto the main form, like this:
NOTE: I couldn't help but add a try..finally loop for the create/destroy flow and replaced Form.Free with Form.Release as is recommended in the Delphi help.
Code:procedure TFormMain.stbsht2ClickBtn(Sender: TObject);
begin
try
SkinManager.Active := False;
SecondForm := TSecondForm.Create(nil);
SecondForm.ShowModal;
finally
SecondForm.Release;
SkinManager.Active := True;
end;
end;Good luck!
Regards,
Hamilton
HamiltonParticipantWhen you run ASkinDemo.exe, what is it called in the task manager? If you're on a 64 bit system (like mine) it is listed as ASkinDemo.exe *32 – it might be worth adding the *32 to the process name and seeing if that matches?
August 24, 2012 at 8:01 am in reply to: Beijing Ext + Ext Borders = incorrect window size on 2nd display #48828HamiltonParticipantAssuming I'm looking at the right thing, if you run ASkinDemo and set the skin to Lightboard and maximize the form then you can see that the top and right sides of the circle around the close button in the top right hand corner have been clipped. I could not notice any difference between the way the form was shown on the main and secondary monitors.
- Using Winter 2011 and Sapphire skins it is obvious that the menu buttons (minimize/max/close) are too high. Other skins are too but these 2 are the worst. The magnifier icon is also too high.[*]Using Lightboard you can see that the top and right side of the round region around the button in the top right hand corner to close the window are clipped.
I think with the Beijing skin it looks like there is more clipping taking place than actually is because the borders are so wide when not maximized. For me, this skin with extended borders was positioned so that the close button was almost next to the right side of the screen. I think there are a couple of pixels missing but it is harder to tell with that skin.
Regards,
Hamilton
EDIT: I reread eledh's last post and this is obviously not the same issue as I'm not seeing anything like the ~400 extra pixels he describes. Tested on 2 systems with no taskbar on the 2nd display, both were a few pixels out only.
HamiltonParticipantHi Serge,
You'll have to run ASkinDemo first – the script is searching for a process called Sys.Process(“ASkinDemo”).
You could modify the script to launch the exe but Jack wouldn't have done that because he doesn't know the path to that file on your system.
I haven't tried to use TestComplete with AC in the last few weeks but I'll fire it up over the weekend and see what results I get too if you still cannot repro.
Regards,
Hamilton
HamiltonParticipantJust to add to the bug report: the issue occurs regardless of whether the checkboxes are shown (the screen grab shows checkboxes).
I don't know if this is the right path or not but IIRC the list view draws the first column border and then copies that to the other columns; it may just be that the cell color for the first column is being drawn one or so pixels too far to the left and entering the region that is copied?
Regards,
Hamilton
-
AuthorPosts