Two buttons on the view toolbar in Delphi disappeared and I can't get them back. One of those buttons is the one to switch between code/unit and the design/form view which I use all the time. The keyboard shortcut for switching (F12) still works, but I have one of those pesky media keyboards where you have to press a function key to access F-keys, so I'd really like to get that toolbar button back.
I tried resetting all the toolbars and their contents, and I see space where the buttons should be, but they aren't there. In the customize dialog for the toolbar, the commands don't seem to even be there anymore.
I tried doing a "repair" re-installation of Delphi, but even that didn't fix it. Has anyone else had this happen before, or have ideas on how to repair or reset my IDE?
edit: perhaps it's worth mentioning the menu options to toggle between code/unit and design/form view are also missing.
As best I can tell, this problem (missing view unit/form button and menu option) could possibly be a limitation of the starter edition of Delphi (this forum post: https://forums.embarcadero.com/thread.jspa?threadID=83324 ) seems to indicate an XE3 user with starter edition has the same missing buttons on their toolbar.
I did discover at the bottom of the screen there are tabs to switch between code, design, and history, which does at least give a mouse-based workaround to toggling between the views without having to expand the file view and click the right pas/dfm file. And the F12 keyboard shortcut does still work as well.
Related
This is my first question, I hope it will be a well constructed one.
I'm currently using Delphi 10.4 Community Edition and I installed SynEdit through the GetIt Package Manager.
The problem I'm facing is the following: I created a VCL form, dropped a TSynEdit in it and launched the application. The problem is that if I press the TAB or SHIFT+TAB, nothing happens. I tried to put breakpoints in the following methods of TSynEdit:
CommandProcessor
ExecuteCommand
DoTabKey
and the debugger never enters them while pressing those keys.
I then looked at the Keystrokes property of my TSynEdit control and, although the keystroke for TAB is defined, I think that the shortcut is "fake". What I mean is that if I try to modify what is associated to the ecTab command and manually choose the shortcut value, nor Tab or Shift+Tab are present in the listbox.
Did anyone ever experienced a problem like this? If so, how did you manage to solve it?
PS: Indentation works with other shortcuts, such as CTRL+SHIFT+I/U.
As indicated by Keith Miller, it was as simple as setting to True the property WantTabs for the TSynEdit control.
Still, if anyone knows why the TAB and SHIFT+TAB shortucts don't appear in the listbox of selectable shortcuts, please let us know.
I downloaded latest Delphi IDE (10.4) and installed it. I turned off the embedded designer and set the layout to Classic Undocked.
Now the toolbar, in fact everything in the top form, is cut off. Can't see the save icons, run button or anything else. Also can't expand the form to make it taller.
If I change to startup layout it will let me expand the form, but I prefer Classic Undocked. Has anyone else had this yet and, more importantly, does anyone know a workaround?
I stumbled on a workaround for this problem. Here are the steps that makes the entire tool panel visible for me in Classic Undocked mode for Delphi 10.4 Sydney (on Win 7):
Grab the right edge of the top form (Classic Toolbar) and resize it slightly (make sure it is in Resizeable mode, not Full Screen). Zap! now everything works. Not only that, it appears to remember the "lesson" permanently once this has been done once - it is a complete and permanent fix.
This bug should be trivial for Embarcadero to fix.
My application is written in delphi. For some reason the main menu does not behave anymore like it did until yesterday (I probably touched some property without knowing). Now when I click on a menu item with sub-items, though the arrow is located to the right, the submenu keeps opening to the left.
What is the reason and how do I restore it back?
As revealed in the comments to the question, this is not programming related. There's a setting that does this in tablet pc settings in control panel. The reason for the setting is, when one is using a pen or the like with the right hand, sub menus, if opened to the right of their parent menu, are obscured by the pen.
I had the same problem and it had nothing to do with my "touch screen" or other pc tablet related settings
I found out by changing some features of the MainMenu of type TMainMenu:
Just set the "OwnerDraw" feature to False and "ParentBiDiMode" to true
So if your parent view is already fine this MainMenu (submenu) will conform to its parent.
I did it 100s of times and it worked for me
I am using the new BrowserField2 in BlackBerry OS5 to display HTML content in my app. There are 3 options available for navigation through links in that content.
CURSOR navigation uses a block cursor and actually moves through the characters of the page. Not very useful for me.
POINTER navigation uses a mouse like pointer that you move around the screen and hover over elements. This could work but there is a bug however in that the browser field captures navigation and never lets go so this mode is effectively broken if you share a screen with any other managers. Once your focus enters the browser field you cannot move focus back out and into neighboring fields. RIM has acknowledged the bug but has no work around.
NONE which is for custom navigation but they offer no explanation as to how you would do this.
What I ideally want is to simply have trackpad movements move the focus through the links and highlight them. Then a click would activate the link. I assume I would select the NONE option above and implement my own focus navigation but I am not clear how this can be accomplished with the new APIs.
Is anyone familiar with the new browser2 component could give some guidance?
Thanks!
There's a workaroudn to getting back the focus out of the BrowserField using the NAVIGATION_POINTER.
I found it in this thread:
http://supportforums.blackberry.com/t5/Java-Development/BrowserField-2-Navigation-Mode/td-p/632172
"farahh" posted this:
I found out a hack..
with the navigation set to pointer mode, a click outside the browserfield manager invokes Manager.invokeAction(int). I used the getFieldWithFocus to verify which field has focus and then switch the focus to something else.
Cheers.
Nahuel
PD: i havent found out how to get the behaviour you want, i need that as well so if you got it working please let me know, its kinda urgent in my project =(
I actually reverted back to the older browser1 (OS4) component because the navigation problems in browserField2 (OS5) were a deal breaker for me. Luckily the OS4 browser does everything I need in terms of functionality and it has the exact navigation behavior I need and there are no focus problems mixing it with other views.
I'm trying to show a popup menu when right clicking my Notification Icon, which works fine; But I want the menu to disappear when the user clicks outside of that menu.
It's supposedly by design as per KB135788 - PRB: Menus for Notification Icons Do Not Work Correctly (archive).
But no decent app I know of behaves like this. I've tried calling SetForegroundWindow using the popup menu's handle to no avail. I'm sure it's possible to work around this, as I've done it years ago but don't remember how.
Anyone know how to achieve the expected behaviour?
I've found a solution!
I was calling
SetForegroundWindow(PopupMenu1.Handle);
Which doesn't work, but changing this in the OnPopup event handler to
procedure TForm1.PopupMenu1Popup(Sender: TObject);
begin
// Hack to fix the "by design" behaviour of popups from notification area icons.
// See: http://support.microsoft.com/kb/135788
BringToFront();
end;
Works!
Obviously, if the form is visible when this is called, your app will jump foremost, but if it's hidden (as mine is), then it'll work.
I'd be interested to know if there's a way to make the menu work right without the window jumping foremost, though.