Forum Replies Created
-
Posts
-
Hi mol, good question! It is probably just habit on my part. I was originally excited when TFrame first appeared and learned the hard way that the original implementation was incredibly buggy and tended to mess with form layout and then save those changes without you realizing. Using descendent frames was a big part of the problem in my case but IIRC I stopped using them altogether when it seemed that even the most basic TFrame could not be relied upon. Your post prompted me to look at some other newsgroups to see how people are using frames these days and it appears that many of the issues have been fixed so I could probably reinvestigate the technology – but tbh I'm hesitant because I've lost a lot of time on this in the past, whereas forms work perfectly every time (border issues aside). The presence of form events is possibly another consideration (though with proper OO code it is an easily surmounted hurdle).
TLDR: habit!
Regards,
Hamilton
I'm amazed I hadn't noticed this before as I'm using docked forms in all my main apps; to the point now I'm so used to seeing my apps look like they do that when that this is fixed I may need to add borders to my docked forms to maintain the current appearance.Anyway can confirm this behaviour exists in 8.04 with all skins and has been around for a long time.
Regards,
Hamilton
Hi,
That last question is a bit of a tough one. Personally I use DevExpress cxGrids and the printing solution in almost all my apps and would find it hard to work in Delphi without them. Since using AC I've stopped using other DevExpress controls and would probably only consider adding very high end controls such as the calendar and gauges if/when I had need for these. For all 'common' controls I'm very comfortable with the AC alternatives and I can't recall any specific DevExpress control that I've removed that took away functionality from my apps – but you may be using the controls differently so you'll need to assess that.
If you create a simple app with a SkinManager, a SkinProvider, a DevExpress TEdit and an AC TsEdit on a form then you'll quickly see the level of skinning provided by both solutions. IIRC the skinned DevExpress component looks OK but the TsEdit is better. Is it 'better' by a sufficient margin to warrant the time to switch controls – that's up to you to decide 🙂 It would only take a few minutes to put one of each of your current controls on a form alongside the AC equivalent and test that, which is what I'd do in your position.
Another quick point – depending on the size of your app you might want to automate the conversion from DevExpress to AC. There is a tool called AlphaConvert on the AC downloads page that will convert any VCL controls in your apps to AC controls (if you have any left over VCL controls). This tool won't help with the DevExpress conversion so you'll want to find something like the free tool developed by the TBX/SPTBX community for conversion of their controls and modify that to work with AC, or a regular text replacement program like Funduc Search and Replace (my own preferred method). After doing the search/replace you'll need to open every form and ignore the properties that are no longer defined, then save the form again. You'll really want to backup your project first in case there are any breaking changes; for some controls you may need or want to convert them manually to avoid missing any important properties.
HTH
Regards,
Hamilton
Hi emailaya,
1&2) This is achieved with the TsTitleBar component. The demo includes source so you can see a working example of this; just take a peek at the TsTitleBar Items list (and in particular the style property) and I'm sure you'll work it out.
3&4) I *think* yes but I'm using an older version of Delphi and cxGrids personally so I can only repeat what I remember other people reporting. The quickest and best way to answer your questions with 100% certainty would be to install it and find out!
Regards,
Hamilton
The project to build the demo also includes something called “ExceptionLog” which is not included in the project. The project compiles if you remove that line; it should be removed from the demo source.
I believe this has been fixed in 8.04 Beta – Ralf can you confirm and close this ticket?
Regards,
Hamilton
Hi Chris,
I can't repro this using the Black Box skin with AC 8.04 Beta with Delphi 2010 on Windows 7. Are you able to update to v8.04 and see if the problem persists on your system? I'd understand if you were hesitant to upgrade to a beta version but in this case I think it is a safe move, and new bugs are getting fixed in that branch so an update is probably inevitable.
PS If you have internal skins, don't forget to go into the skin manager and click “Update All” to get the latest versions of the skins – I think you'll have issues with version 8 if you don't.
Regards,
Hamilton
Hi,
If you're not concerned about image quality then this seems like something that could be implemented fairly easily. However, if the image quality is important then this concept is a *lot* of work. I use the Graphics32 libraries (http://graphics32.org) for this purpose myself because the VCL image resizing routines are *TERRIBLE*. Put it this way: if you have an image 128 pixels wide to fit into a 32 pixel wide image then Delphi routines remove every 4th pixel from the original… sometimes it works just fine other times you end up with garbage. I don't know if you could, or would want to, hook in an advanced library like that to do the resizing but if you don't you might not get a result you'd want to use.
Some graphics programs allow command line parsing for functions such as resizing images and IMO you're probably better off looking into that, or manually resizing your images in a graphics program (not Paint) and then saving them in a new list the correct size. HDD's and RAM are cheap and there isn't much benefit worrying about things like that when the OS you're building your app on doesn't.
This is all just my opinion though, who knows Serge might have some tricks for this up his sleeve, or maybe icon style images are small enough that the quality doesn't matter.
Regards,
Hamilton
EDIT: This post clicked me over from being “Advanced” to “The Aged”. I don't know if it was worth it!
Serge, what do you think? Would it upset other users if mouseover effects were retrospectively added to existing skins? I'd hope they would really like it but don't really have any finger to the pulse to know how it would be received.
Sasha, multimedia dev sounds like fun! Most of my apps are grids and edit forms, though we did some POS stuff recently that was a bit different. I should be careful what I say about skins because I can get it wrong, when I say that blackbox doesn't suit our business apps it wouldn't surprise me if some of our clients love it. Most of our apps include per system or per user skinning options; I once put DeepPurple in a new app I was developing in order to distinguish a particular test server and included that skin (which to my eyes looked horrible with the particular app) solely for that purpose – and the very first client we installed that system for noticed the purple skin, declared that to be their favorite colour and made it the system default. Now whenever I walk into that site I can see my app – in purple – on every monitor.. well it is not what I would have chosen but it makes them happy so I guess I can be pleased with that 😛 I know DeepPurple is another one of your works and I'm definitely not knocking the skin per se – it's just that I've never seen a purple access control system (or anything else for that matter) at a major public hospital before!
PS To balance things out, I feel I need to add that Subway and Android OS are amongst my favourite skins – love your work!
PPS Could this be more off-topic? I need to get back to work, ciao!
Regards,
Hamilton
Thanks for reporting this mol, I've had clients tell me this is a minor nuisance for some time and I hadn't gotten around to documenting it yet.
Just to generalize the conditions already reported, you can actually repro this with any AC app at the moment by:
- Maximize the app – either at design or runtime.[*]Minimize the app – by clicking the minimize button or some other code[*]Restore the app – by clicking on the taskbar or alt-tab or some other code.[*]Observe the app is in the normal state and not maximized as it should be.
Regards,
Hamilton
I compared TsButton and TsSpeedButton, both had ParentFont set to true:
TsButton
* In the IDE, this gets the parent color even if CustomFont is FALSE.
* At runtime, TsButton works as expected
TsSpeedButton
* In the IDE, the font is always black
* At runtime, TsSpeedButton works as expected
mab88 are you getting the same results? You didn't mention IDE vs runtime in your OP so I'm not sure if the problem persists for you to runtime? If it does, can you check that you have the SkinData.CustomFont set to TRUE please?
Regards,
Hamilton
Full points for writing style 🙂
I hadn't used these controls before and after seeing your screenshots I had to try them – and now I need to use them! I haven't used them aligned like in your demo but rather as headings and the shift makes it hard to use for even that purpose as you have to leave a huge white space around the LabelFx to cater for the various jumps that the skins make it perform. The worst offenders are Opus and Blue Glass – these move the text by a lot more than a few pixels and create a real alignment problem. The horizontal and vertical shift are both uneccessary and should both be removed IMO. Still, the labels add a really nice effect to my programs so I'm going to use them selectively in a few places anyway and wait for the fix I'm sure will be forthcoming shortly before using them in a wider context. Or in the parlance of the OP – I'll date but wait for a little self-improvement before taking things to the next level ;p
Regards,
Hamilton
Hola Victor,
I don't have C++ Builder so I couldn't run your demo but I did convert the core of it to Delphi and I'm unable to reproduce the problem. Can you run the exe in the attachment and confirm it looks OK on your system? If you have Delphi, are you able to compile the code and get the same result?
The problem may be specific to C++ in which case I'm unable to help. The AC team may be able to do more but they're likely to want to know your C++ and AC versions, so if you provide that it may get you a quicker result.
Sorry I can't do more. Buena suerte.
Regards,
Hamilton
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
