Forum Replies Created
-
Posts
-
Hi Serge,
This remains the one standard VCL control I use regularly that is not skinned; if you're looking for something to do in your spare time this would be a good project!
I won't bump this thread again.. just couldn't resist doing it once, hope you don't mind too much.
Regards,
Hamilton
It appears the attachment is a 7-zip (7z) file rather than a zip but has the wrong extension. If you google 7-zip you'll find the free program that will allow you to extract the project.
Hi Kurt,
I tried to repro this and cannot. I put two buttons on a new form, made sButton1 quite large and sButton2 has the OnClick even which says sButton1.Enabled := not sButton1.Enabled. For me, the caption stays in the centre and the disabled button looks as I'd expect. In my testing the only way I could get the button caption to move was to make it a CommandLink. Anyway I've attached a screen grab that shows how the disabled button appears in my test app. I wonder if you get the same results with a simple test app; if you can then perhaps you can break your program down into smaller chunks to identify what is failing. Good luck.
Regards,
Hamilton
Hi Serge,
I fixed this in my main projects by reloading all of the skins so this issue is no longer a showstopper for me.
The bug does still exist however. I could send you a demo app but I believe you should be able to repro this just by:
1. Create a new VCL forms app
2. Put a TsPageControl down
3. Add a tab to the page and notice that the caption does not display in the IDE or at runtime.
I've attached a screen shot that shows this. Do you get the same result?
After further testing I can add a step 4 above:
4. Add a SkinManager and SkinProvider to the project and the captions appear
In my existing projects the tab captions did appear at runtime but did not appear at design time until I reloaded the skins. For my sample app the captions did not appear at either design time or runtime until I added a skin.
PS I'm not using TnT but I am using DevExp v6.
Regards,
Hamilton
Hi Serge, I can confirm that the version that shipped with 7.58 corrects the check state drawn. Cheers.
Hi Serge,
I've re-downloaded the skin from the link in your earlier post in this thread and the problem still occurs.
Regards,
Hamilton
Perhaps the link is wrong? I re-downloaded the file, deleted the old skin from my program and readded it (copy/pasting the path to ensure it is correct) and then ran it – same results. The other confirmation that I've loaded the new skin is that the case on the name has changed (previously DeepPurple, now deeppurple on this new one).
The problem with the reimport messing up the indexes still occurs, any chance of a fix pls? The messed up indexing doesn't occur all the time but its often enough to negate the usefulness of this handy feature.
If you cannot repro, one thing you might try is to rename one of the skins and then try again. I don't know when this first occurred but at some point DeepPurple became deeppurple and I've had to rename that skin in the skin manager for compatibility with the rest of the program (as unfortunately the skin name appears to be case sensitive). So what might have happened this last time is that it failed to load DeepPurple because the file was called deeppurple and then that in turn may have messed up other skins also? Just guessing..
For your second question, I've also asked for this control to be supported and been told it may be in future. In the meantime you can manually skin the control, there is some code for how I'm doing this in the forum thread here.
Use one of the following:
Code:sPageControl1.Pages[1].TabVisible := False;
sTabSheet2.TabVisible := False;Regards,
Hamilton
Not that I'm aware, though Serge would give you the definite answer. In my experience, Delphi toolbars are really lacking in important features and if you want to have anything other than a standard left aligned toolbar then you're better off doing something custom – for instance, in almost all my apps I use TsBitBtns on a TsPanel, that way I have full control over the buttons. The only caveat I'd add to that is that for my apps I make sure that TsBitBtns use the TOOLBUTTON skin section (SkinData.SkinSection := 'TOOLBUTTON';). Best of luck.
Regards,
Hamilton
Hey how are you converting the controls? I've updated several apps to AC and haven't had any problems like you describe. I don't know if there is a better way but this is how I'd do it:
1. Add a TsCheckbox, TsComboBox, TsEdit and any common controls you'll want to use to one form and save it so it builds the include list.
2. View the form DFM as text and replace TEdit with TsEdit in the DFM (to view the form as text just show the form normally then press Alt-F12).
3. Press Alt-F12 to switch back to the form then F12 to view the code.
4. Replace TEdit with TsEdit in the code.
5. Repeat steps 2 to 4 with each control you're updating (eg Replace TCheckBox with TsCheckBox next, then TsComboBox, etc).
6. Copy the “uses” from this updated form onto the next form you're going to work on, then repeat steps 2 to 5.
The important things here are:
1. Make sure you're including the AC units (ie by putting them in the “uses” section) for the controls you want BEFORE changing the controls over.
2. Update the DFM BEFORE you update the code. If you change the control in code first then Delphi will raise and error about a type mismatch and won't update control like you might expect (if you're not careful it will remove it).
3. Update one type of control at a time until you're comfortable with the process and certain that you're not losing data. If you're certain that all of your forms have the same controls then you could update the uses clause in all of them (maybe with a bulk search/replace) and then do a bulk search/replace to update the control types. If you don't know what I mean by this then continue to update the controls one at a time.
4. Compile after updating each form and save each form after you've finished editing it.
Good luck.
I *think* you're saying that you had a tray icon control but when you used it to show your application the skin was not displayed properly? If that is the case you might be able to fix it by trying the following one step at a time until the problem goes away:
1. Add a TsSkinProvider to your app main form if you haven't already.
2. Comment out everything in your form Create/Destroy/Show/Close/Activate/Deactivate events and see if the problem persists.
3. Change the events on the TrayIcon control to Hide/Show your form rather than performing some animation event.
4. In your FormShow event, reinitialize the skin manager. Try just setting the skin eg SkinManager.Skin := 'WEB (internal)'.
5. Download the Jedi VCL library and use their tray icon.
Good luck.
Hi Serge that is fantastic! The “Update All” action replaces 10 skins so fast there is hardly even a flicker, it's 1000 times faster than I can do it and it completely removes the human error element.
Having said that, I did find that 3 of the 11 skins in one app were updated with the wrong skin. For example, a skin called DeepPurple (internal) loaded WMP. I manually deleted/re-added the skins that had problems and from then on everything worked perfectly, including multiple repeats of using 'update all'. I didn't notice that anything had changed about the skins with the reimport (they definitely had the same name and other properties that are visible in the skin manager) so I think it may have been an indexing issue. I haven't tested this fully but I think what happened is that the skin called DeepPurple loaded WMP, WMP loaded Golden, Golden loaded DeepPurple. I can get the old SkinManager that exhibited this behaviour out of the repository if you need something to test this with.
TLDR: If anyone finds that “Update All” loads the wrong skin then they can probably solve it by reimporting the skin manually once, from then on it should work.
Regards,
Hamilton
Delphi 2010 has a TTrayIcon which I think was introduced in 2009. If you have an older version of Delphi then you'll find that Jedi and many other vendors provide free tray icon controls. The only part of a TTrayIcon that is visible is the icon in the tray, which will not be skinned anyway, so there is little advantage to having an ac version of that. The popup menu associated with the tray is another matter – TPopupMenu could be skinned but isn't currently.
