When TWebBrowser control is too small it becomes greyed.
If TWebBrowser control is aligned to alClient and there are no other controls on the form I can make it really small (50x10 for example). However, when I add other controls like panels, toolbar, main menu and so on which all float on top (alTop) - the more controls I add it seems, the smaller window of TWebBrowser I can get without greying itself. When window is resized to become larger, then it becomes ungreyed again.
In this example I placed TToolBar with 2 buttons aligned to alTop, and TWebBrowser aligned to alClient. If I make toolbar invisible, I can make web browser really small. However, with toolbar visible it greys itself. The more controls I add it seems to have less and less usable space before greying itself.
As you can see in last example web browser is even smaller than in second example but still visible and everything is the same except there is no toolbar on top. Same applies if used on Windows 7 or 8 or with Internet Explorer 10 or 11.
The examples here are just examples. I don't have a problem with having 100x100 control as minimum size. The problem is that when I place quite a bit of controls then it doesn't allow me to have smaller control than 550x250, which is quite large.
Can anyone enlighten me why other controls have an effect on web browser not being able to use smaller size when it can do this perfectly normally when there are no other controls on form?
Many thanks to bummi in the comments up there for finding a following workaround:
It appears that the problem with greyed control doesn't appear in XE3 and later but can be reproduced in earlier versions like XE2, XE, 2010 and 2009.
For these earlier versions the workaround is to place TWebBrowser on another control such as TPanel and then align both controls to alClient (so that the TWebBrowser fills entire TPanel and TPanel fills entire area previously filled by TWebBrowser). Of course, alignment here is not an issue but the workaround is just to place one control on another.
The same works for TEmbeddedWB and probably other controls that host Internet Explorer ActiveX control.
When placed on container control like TPanel, web browser can be resized to any size without the problem described above.
Related
I have two controls on my form.
TWebBrowser with Align set to Client
TMemo with Align set to None
I want to display TMemo on top of TWebBrowser for a particular scenario and for that am using Memo.BringToFront but it does nothing.
Am I missing something?
TWebBrowser Is a particular firemonkey Control. Firemonkey control are "paint" according to their z-order on a openGL surface (ie: the form). but TwebBrowser is a native control that is draw on another surface that is placed on the top of the form, hidding in this way everything back to it.
The only way you can do is to show you memo inside another window on the top of the TwebBrowser. for this you can use a native Memo. As far as i know their is only one native memo implemented on android (delphi already have some that work on ios/windows) it's https://github.com/Zeus64/alcinoe
Delphi 2010 - all patches, Win 8.1 64 bit. Reinstalled EVERYTHING... windows,etc, so functionally a new machine. Installed D2010, then installed GExperts and CnPack Wizards, as I had used them both before a really liked them.
I have 2 monitors, so I changed my layout to Classic Undocked. The default is to have the component palette at the top right of the Delphi main window.
In my previous release, I was able to change the HEIGHT of this window to double whatever it is now, and drag the palette UNDERNEATH the glyphs from the File / Edit / Search area, so that way my component palette went across the whole screen. For whatever reason, I cannot do this now. When I move my mouse to the BOTTOM of the delphi window area, I get the "expand window up and down" cursor, like I should, but the window refuses to increase in height. There is some setting preventing me from increasing this windows height, but I can't find it. What setting am I looking for in order to be able to increase the height, so I can drag/drop my palette to the bottom LEFT corner of this window?
Thanks
The size of the main undocked window cannot be modified by resizing it manually. It is sized so that it is exactly large enough to contain its children. So, you can do what you want by moving the component palette to the desired location. When you do so the main window will increase in size so that the component palette fits.
Judging by your screenshot, your toolbars are drawn in a way to indicate that they are locked and cannot be dragged. That's not functionality that is present in the plain vanilla Delphi IDE, so I suspect that you have used functionality from either GExperts or CnPack to lock your toolbars. Obviously you'll need to unlock them in order to move them.
Finally, I should point out that the inability to resize the main window vertically is not new. Classic Delphi versions (e.g. Delphi 7) behaved in exactly the same way. So I think that the fundamental issue is not related to a Delphi version upgrade, but rather is related to you having locked your toolbars.
I have a form filled with a TImage. I put over this a TGridPanel. If themes are enabled in Windows 7 the TGirdPanel appears with transparency. If themes are disabled (no visual styles) the TGridPanel loses transparency and hides the part it ocupies. I use Delphi XE2
Is there any workaround for this?
That's a basic fact of life for panels. It's not special to the TGridPanel, you will see the same effect for any control derived from TCustomPanel. The transparency is only supported when the application is themed.
The grid panel is just a convenient way to layout your controls. If you want to support running unthemed then the simplest solution is to remove the TGridPanel and layout your controls manually. That's pretty much trivial to do. Handle the OnResize event of the control that currently contains the panel, and position your controls as desired.
In Google Chrome when you click the mouse wheel button you get this cursor:
And then you are able to scroll to all possible directions, when you move around with your mouse...
IE also has this, but only moves up and down:
Is there any component for Delphi that can do this? (for a TScrollBox for example)
TMemo, for example, can do that for you, provided you set its ScrollBars property to something else than ssNone. It will even adjust according to which scroll bars are enabled. Problem with TScrollBar component is that on its own it doesn't have any focusable parts and won't receive OnMouseWheel(/Up/Down) events, but its included windowed controls might. You could write a workaround for that on main form events, though. Check solutions at http://www.delphipages.com/forum/showthread.php?t=197309
EDIT: OnMouseWheel(/Up/Down) should be OnMouse(/Up/Down), thanks to #Sertac Akyuz for pointing this out ;)
Seems like this feature is available in RAD studio 2009 (but not in D7).
You need to use Imouse (imouse.pas unit) and the control must have ControlStyle of csPannable.
quote:
Imouse (imouse.pas unit) is a standard implementation of scrolling
with middle button (called also "mouse panning"). It's also used in
RAD Studio. Imouse functionality relays on standard window scrollbars
and sends WM_HSCROLL/WM_VSCROLL to the window to make it scroll. It
works on every window, that have a scrollbar (e.g. TListView,
TTreeView, even TForm/TFrame if AutoScroll is True and at least one
scrollbar is visible).
Oh, I've forgotten one thing. Control must have csPannable in
ControlStyle, but RichView hasn't by default. So, after adding Code:
RichViewEdit1.ControlStyle := RichViewEdit1.ControlStyle +
[csPannable];
I didn't test it though.
All that is left for me is to look into the source code (When I can get my hands on copy of D2009) and maybe impliment this with D7...
I'm working on a Windows Deskband in Delphi XE2 for Windows XP, Vista and 7 (Win32 and Win64)...
I've implemented all the necessary interfaces (ITrayDeskBand, IDeskBandInfo, IDeskBand2, IDeskBand) in my code, and that all works exactly as it should (there are no warnings on Vista/7 complaining about compatibility as others have experienced).
The problem I have is that my Deskband Form appears with a non-transparent band. Also, only certain Controls are displaying (in this case TBitBtn and TImage containing a PNG). I need it to display TEdit and TComboBox objects properly too, but they won't appear at all.
I've tried enabling GlassFrame and SheetOfGlass properties on my Form, but this doesn't help one bit.
Furthermore, the Form itself is exceeding the top boundary of the Taskbar, meaning you cannot (for example) resize the Taskbar if the cursor is in-line with the top of the Taskbar immediately above my Deskband.
I believe there is something Delphi's VCL TForm type is doing behind the scenes which renders the TForm type incompatible as a Deskband container... but this is just a suspicion.
Here's a screenshot illustrating the various problems:
As you can see (above), the Deskband's Form is pale (instead of Transparent), it overlaps the top of the Taskbar (preventing resizing and Autohide triggering when the Taskbar is "hidden")
Any ideas?
UPDATE 1
Okay, I have been playing around and noticed that a totally different behaviour is observed when creating a TToolBar control to be used for the Deskband, rather than a form:
Notice there are three TToolButton controls (with their text virtually invisible due to the Glass theme)? There should also be a TEdit and TComboBox between two separators, but these refuse to display at all.
Also notice the artefacting (the repetition of actual Taskbar Icons)?
I'm not sure if this is a step in the right direction or not, but it might help you (or others) to deduce a solution!
Okay... I've finally figured this out, and it is the most absurd thing I've ever come across.
I'm posting my findings here for the benefit of others (to save you going through the nuisance I've just been through).
To get all of the controls on your Deskband Form to display and function properly, simply set the Visible property of your Form (in the IDE designer) to True.
Ridiculous, I know, but it works and is easily repeatable.