I am running Delphi 2010 on both a 64 bit windows machine (Win 7), and a 32 bit windows machine (XP).
I am trying to learn how to use the TRibbon control.
I have been following the example in Marco Cantu's 2009 Handbook and watching YouTube Demos, but my control is not working like that as explained in the book or demos.
I added two tabs, by right clicking the control. However, the TRibbon looked as exactly as it does in my screenshot, when i drop it on the main form. It is not as high as the ones in the books or youtube demos.
I have tried the same thing on my Win 32 laptop running Windows Xp and Delphi 2010 and get the exact same results
here is what it looks like on my machine
here is what it is suppose to look like in a demo
Once again. When it drop it on the form, it does not take the shape and height as that as i see in the demos. Even when i add tabs. Did i do something wrong during my Delphi 2010 installation?
I managed finally to reproduce the problem in Delphi XE (Update 1) on Win7 64 with Aero enabled. It seems that the size gets set wrong in the .DFM file, and because the Ribbon doesn't support manual resizing you can't visually fix it in the IDE (although it appears correctly at runtime) or in the Object Inspector. It occasionally appears correctly at runtime, but it seems that's sporadic as well.
It's a nasty bug, because it makes it impossible to design the Ribbon. You can add RibbonGroup items, and assign the ActionManager, and try and design it completely using the Structure Pane, but of course that's not a practical solution.
Fortunately, there's a pretty easy workaround, although it's annoying to have to do. :)
I managed twice to get the following workaround to function, but starting over it failed to work several times, so it's a possible way around it (no promises - worked in XE, consistently failed in XE2 Update 2):
Right-click on the Ribbon and add at least one tab.
Right click on the form in the IDE, and choose View as Text from the context (pop-up) menu.
Find the Ribbon control in the .dfm text, and change the Height from the 26 that the IDE assigned to 200. (The next step will adjust it, but that's fine - the 200 fixes the immediate problem.)
Right-click again, and choose View as Form, and the Ribbon should display correctly.
(I reported it in QC against XE2 Update 2, as the problem also exists there - QC #101642)
I traced it to TCustomRibbon.GetCaptionHeight, specifically
FCaptionHeight := Max(GetSystemMetrics(SM_CYCAPTION), 26);
It seems like the GetSystemMetrics call is returning something less than 26 on certain Win7 configurations (although I can't figure out why yet). There are a couple of commented lines in that method that seem to alter the result, but as I said they've been commented out.
The strange part is that in the TCustomRibbon.Create, the Height is set by a call to GetRibbonMetric(rmFullHeight), which sets the Result := cRibbonHeight + GetCaptionHeight;, and cRibbonHeight is a constant defined as cRibbonHeight = 117;.
Finally think I've tracked this down. In the declaration of TRibbon, there's a published property declaration:
published
...
property Height default TCustomRibbon.cRibbonHeight;
Because this is the default, it appears that any other value means that the call to GetRibbonMetric mentioned above doesn't happen (see the TCustomRibbon.Create mentioned above), and the strange result from the call to GetSystemMetric causes the erroneous value 26 to be saved as the 'other value`. Wierd; will update the QC in the AM.
Addendum: Updated QC report with additional details.
Addendum: QC report opened in May 2012, but does not appear to have been resolved as of XE5 Update 1 (checked Jan 2014).
Related
I am experiencing a crash / exception when using a simple TOpenDialog with VCL Styles enabled.
Without the styles enabled, the dialog is of course working fine. The issue occurs with C++ Builder 10 and 10.1 Professional.
To reproduce:
create a simpe VCL Form that uses styles
add a TComboBox, a TButton and a TOpenDialog to the form
add the following code to the OnClick event for the button
OpenDialog1->Execute();
for(int i=0; i<100; i++)
ComboBox1->Items->Add("test text");
ComboBox1->ItemIndex = 1;
run the application, click the button and select a file
For me, this yields to an exception 'Out of system resources'
This bug could be reproduced on Windows 7 Enterprise and Windows 8.1 Pro.
Having the same issue with a TSaveDialog.
The weird thing for me is that regarding this exception, I can't find similar issues on the web. In my opinion, with only VCL styles and TOpenDialog required to have this, I would expect more information about this on the web.
I only found something remotely similar, but not an exception there and also no solution in terms of native VCL styles:
Using custom styles shows invalid characters when right-clicking a file in TOpenDialog
I tried also to disable SystemHooks shDialogs (please see screenshot) which I read somewhere regarding another problem with VCL styles, but to no avail.
* Edit 2016/05/26 *
Remy Lebeau is asking for a MCVE. I tried to put everything in the question, but for clarity here an abstract for a MCVE:
create new VCL project with default settings
drop a TComboBox, a TButton and a TOpenDialog into the form
add the following code to the OnClick event for the button:
void __fastcall TForm1::Button1Click(TObject *Sender)
{
OpenDialog1->Execute();
for (int i=0; i<100; i++)
ComboBox1->Items->Add(L"test text");
ComboBox1->ItemIndex = 1; // <- exception occurs here
}
enable a VCL style 'Smokey Quartz Kamri' in the project options
run program, press button, select any file and select OK in TOpenDialog
Here, this is really all it takes for the exception.
In my opinion, the call to Execute() messes up some VCL structures (only if styles are enabled) and then the access to another VCL item (combobox in my case) leads to the crash.
I am now aware that not every one has this crash. So forgive me if it is not a 100% verifiable example for each of you.
But me and my colleague can't be the only ones who have this crash (tested now on 4 different computers with 3 different OS versions), can we?
* Edit 2016/05/27 *
Regarding Tom Brunberg's request for single step, the exception occurs somewhere within WndProc, in the screenshot at address 005459F4 within the call.
If I step further, I am landing somewhere in TCustomCombo.WndProc. After that is is very hard to follow further because of repeating loops in WndProc, can't seem to reach the final place where the exception fires.
* Edit 2016/05/27 second *
OK I managed to pinpoint the exact location of the crash. Is in in the function CopyBitmap within VCL.Graphics. In the first screenshot, exception occurs at line:
Result := GDICheck(CreateCompatibleBitmap(ScreenDC, bmWidth, bmHeight))
In the function GDICheck() in the second screenshot, the variable Value is zero in the debugger, so in turn function GDIError is called. There, ErrorCode is zero as well, this leads to the call to OutOfResources.
Hope this helps to narrow it down further.
* Edit 2016/07/19 *
Since nobody here seemed to have the issue, we gave it a different try:
A colleague of mine in the company did a fresh C++ Builder 10.1 Berlin install, in English (thought maybe the German IDE is the culprit),
and first thing after the install, recreated the StylesCrashTest App. Result is the same, it crashes at once after selecting a file and hit 'open' in the dialog.
I have uploaded the test project here
http://fboom.me/file/9904e22ddd22b/StylesCrashTest.zip
and our generated release exe here
http://fboom.me/file/368d0b62cc1a7/StylesCrashTest.exe
The exe is tested with many antivirus scanners on virustotal.com.
https://www.virustotal.com/de/file/e96f2e7eb80c162c2e5998decc15f26615c9fc76efec73379dd2e2140e4eba08/analysis/1468952442/
It would be helpful if you guys could test the exe and the test project and this could lead to separate the issue to either computer related or related to the installed IDE/generated exe. This of course only if someone can reproduce the issue.
With this exe, the app crashes here on two Windows 7 x64 Enterprise computers in a commercial environment.
It does not, however, crash on my private computer with Windows 8.1 x64 Prof.
Right now I am at a dead end, nobody outside the town of Munich seems to be able to reproduce the issue, but we have it definitely on two different computers.
The issue is also filed with Embarcadero (login required):
https://quality.embarcadero.com/browse/RSP-15019
Sadly, at the moment, this is a shop stopper for us for using VCL styles.
I found a fix to get rid of the crash. After some more debugging, it was discovered that the exception occurs every time TBitmap::SetSize is called with a negative parameter on the VCL styled TComboBox.
Please see the call stack in the attached screenshot:
TComboBoxStyleHook::ListBoxWndProc
TComboBoxStyleHook::DrawListBoxVertScroll
TBitmap::SetHeight
TBitmap::SetSize
After editing SetSize() in Vcl.Graphics.pas to exit on negative numbers the exceptions seems to be gone.
This is no fix for the cause of the exception, because why the parameter is set to -1 in DrawListBoxVertScroll is still unknown (bug?, could also be the result of a lot more sub calls within this routine), but at least it is
a fix to prevent the exception. Tested on all our machines where the exception took place with positive results.
Would love to hear the opinion of some real VCL experts like Remy Lebeau or even the VCL developers about it, though.
Again, I realize that not everybody can even reproduce the exception, but with the test project linked above, the exception is inevitable on our systems.
Delphi XE2 Update 4 Hotfix 1 and Help Update 6 for XE2.
If I am in the IDE, highlight an object name such as TLabel, then hit F1, I am transported to the description of Vcl.StdCtrls.TLabel in Delphi's help application. The page gives me information for both the Delphi and C++, but I can click on Display Preferences in the top right and 'un-tick' C++ so only the Delphi information is displayed. But now, if I click on TEdit (either by clicking within the help page under See Also or by selecting and F1-ing in the IDE), the Display Preferences automagically reverts to both Delphi and C++ when the TEdit Help is displayed.
If, on the other hand, I go directly to embarcadero online help, for example: http://docwiki.embarcadero.com/Libraries/XE2/en/Vcl.StdCtrls.TLabel to get the same information (using Chrome), the browser (?) remembers my Display Preferences and, once I have un-clicked C++, will only show me the Delphi information if I click on TEdit or further pages.
This drives me to distraction, as I am not the least interested in C++. Have I missed some option within XE2 to only select Delphi in Help's Display Preferences, or is this a 'feature'.
I don't think there's anything you can do with XE2's docs to fix this.
This was improved on in XE3's documentation, and improved even further in XE4's and since there have been four versions released since XE2 there won't be any further updates to it.
(You can't compare the online documentation with the local disk documentation; the first uses the functionality of the web browser, while the second uses the functionality in the MS documentation viewer, which happens to contain a web browser control but implements the functionality in the app itself instead.)
Answer by Ken White
I'm using Delphi XE2 Update 3. Update 4 is not compatible with some of our 3rd party components, so we haven't updated yet.
I use TImageList's in my applications. I've noticed that many times when it toggle from source view to form view (F12), suddenly the previously unmodified unit will be modified. If I save the change caused by pressing F12, I can look at source control and see a few bytes of the TImageList.Bitmap property have changed. Here's one example as seen in TortoiseHg Workbench:
## -830,7 +830,7 ##
Left = 760
Top = 480
Bitmap = {
- 494C01010200E402E40210001000FFFFFFFFFF10FFFFFFFFFFFFFFFF424D3600
+ 494C01010200E802E80210001000FFFFFFFFFF10FFFFFFFFFFFFFFFF424D3600
^^ ^^ <-- two bytes changed
Sometimes there are other minor changes, but it's always limited to just a few isolated spots in the TImageList.Bitmap data. It's a real pain to be constantly pushing these insignificant changes into source control when I'm not making any intentional changes.
Does anyone know why Delphi change the TImageList.Bitmap data when toggling between source and form views? Is there a way to workaround this limitation?
It is a really annoying IDE bug already reported sometimes in Embarcadero Quality Central, especially in QC 92769, but unfortunately it is not fixed yet. :-(
Win7/x64, Delphi 6 Prof.
Win7 drives me crazy with his side effect. I describe it:
When I force the suggestion with Ctrl+Space, or Delphi do this automatically, the Delphi don't show the suggestion dropdown listbox, he is only bring my all opened forms to front, one by one.
This causes that what I typing is not going to editor window: it is going to any property of the active form, of the active control.
For example.
Ctrl+Space+"ShowMes..."
I don't got ShowMessage with suggestion listbox, I type ShowMess into my main form's caption.
Many times I need to make update pack's because the buttons, caption, etc got "ShowMes" or "Excep" or other property, because I type into these windows...
This function is sometimes broken on win7.
May I can restore the normal working mode without "bring all opened form to front"?
Thanks:
dd
You can disable UAC in Windows 7, see here:
http://www.petri.co.il/disable-uac-in-windows-7.htm
Also running Delphi 6 in Windows XP compatibility mode should do the trick.
See this discussion on the embarcadero forums, it's about Delphi 7, but it's the same issue:
https://forums.codegear.com/thread.jspa?messageID=204928&tstart=0
Finally see here how to run a program in XP compatibility mode:
See: http://www.w7forums.com/application-compatibility-mode-t314.html
Or: http://www.sevenforums.com/tutorials/316-compatibility-mode.html
In a Delphi 2007 program I am using a TMainMenu referencing actions in a TAction list. I have prefixed the hotkeys of all main captions with an ampersand:
&File | &Edit | Ev&aluate | ...
In design view these hotkeys are underlined as I would expect, but when I start the program they no longer are underlined but they work nonetheless. In contrast to this, for all the submenu icons
&File
&New ...
&Open ...
the underline is shown as expected.
I am aware of the Windows pisplay properties option "Hide underlined letters or keyboard navigation until I press the Alt key." and have disabled it. In all other programs this works fine, including the Delphi IDE.
If I create a new VCL appliation and just add a TMainMenu and a few menu items, it works as expected.
This has me baffled, really.
Is there any property of the TMainMenu component or maybe an application option that I must change? The "Enable runtime themes" project option is grayed out for some reason, might that be the problem? If yes, what causes this?
This may not be a Delphi issue. I have just tried this with IE8 on WinXP. On my machine, with the display properties set to require the Alt key, the underlining works as expected. However, with the checkbox unchecked, the underlining never appears on the main menu items (even when using the Alt key), but always appears on the File,Edit,View etc submenus (as you describe) ........ unless Microsoft wrote IE8 in Delphi :-)
I asked the same question last year and there were some excellent answers:
Menu Accelerator Keys Not Showing Up Delphi 2009
In conclusion, it appears to be a Delphi bug, and I reported it to Embarcadero at:
http://qc.embarcadero.com/wc/qcmain.aspx?d=68816
However, they have no resolution to it, so unless others (maybe you) also complain, I don't expect it will get addressed.
Step's answer to my question refers to a possibly related bug reported on the Delphi forums:
ALT Key press causes controls to disappear under Themes in Vista and XP. This one is marked as "resolved" with several possible fixes listed in the comments. I have not had the opportunity to go through these.
By the way, since I asked that question last year, I got a new computer with Vista. The same problem still happens, even when the Vista Ease of Access Centre setting: "Underline keyboard shortcuts and access keys" is set. So the Delphi bug still exists.
I was very surprised to find the default was that this was unchecked. I guess in Vista, they want a cleaner looking menu with the assumption that not many people ever used the accelerator keys.
The easiest way to fix this problem seems to use TJvMainMenu from the jvcl instead of TMainMenu. I tried the current version 3.38, but it is possible that the problem was fixed already in earlier versions. Since I was using the jvcl anyway it does not add much to my program's size. Your mileage may vary though, the jvcl is a huge library.
Uses an empty image list for main menu, if it is possible. In this way you can force delphi to paint menu correctly. (But looks ugly in vista and w7)
Are you sure you don't have OwnerDraw set to true in the MainMenu?