So, I did a search and nothing pulled up.
Microsoft's definition of GdiVerticalFont is vague:
true if this Font is derived from a GDI vertical font; otherwise, false.
Huh. Really? So I'm thinking I shouldn't be messing with it; however...
Here it is, available for anyone to change, in the Visual Studio designer.
(FYI: I hacked this pic off another SO question)
I have only ever seen it set to FALSE.
I tried changing it to true, and noticed nothing.
What is this for?
Related
When looking at member in Locals, the wrench means a property and the heart means internal:
But when pinned, the heart is replaced by a stop sign:
Question:
What does the stop sign means?
Looking at Visual Studio Image Library turned out to be useful:
Not sure why it sees it as sealed but at least I have an answer to the question.
The default search scope is always 'Entire Solution' which just BEGS for the end user, at some point, to exercise the option in Source Control to undo pending changes. :)
Is there a way to have a blank in this drop down or custom set it to Current Document?
Personally, why invite disaster as the first option? Let's have the Nuclear Option as one that must be intentionally selected, not just set it as the default.
It's obviously not because of an alpha setting, since Current Document should come up first if that were the case, which means someone decided this was the best default, maybe the guiding thought is 'Let's just see who's not on their toes today.'
Enough of a rant ... if there is a setting to force Alpha Order, that solves the issue. If it can be customized, even better.
Thanks!
I'm updating some legacy code, because of my unfamiliarity to it, Its very difficult to find structures, especially if I step away for a week for other projects.
To alleviate this problem I've gone back to my old-school roots and started adding ascii text-art as comments above sections of code, using this tool:
http://patorjk.com/software/taag/#p=display&h=3&v=1&f=Big%20Money-ne&t=Reveal%0ACheck
This allows me to see via my MiniMap the titles of functions or sections of code I might need to come back to
The Thought then occured.. well surely someone else has this problem, and since VSCode seems to be written by the community, maybe someone has already written a plugin that would search the code for function titles (like Javadocs?) and display the title in a readable size?
If not, would it be easily coded? i.e. is the minimap just a very shrunk down copy(not easy) or is it structured and can be parsed and tweaked?
As long as your language plugin supports it, you can use cmd + shift + o to go to function definition.
All functions should also be listed in the Side Bar under "Outline"
It is nice that Firemonkey got again the Hint property for controls, at least in Delphi Berlin and Seattle.
However, the implementation seems to be a bit flawed yet.
One weird issue is that the displaying of the Hint seems related to the form's BorderIcons property. If the BorderIcons are left with the default values (Maximize, Minimize, SystemMenu), the hint shows. But if I change some of the border icons, the hints don't show any more. I don't see any logic for it, so it looks like a bug. I traced some code in the FMX.Forms unit, but couldn't find any relation to the border icons. The hints in TriggerControlHint and other methods seem to be set correctly.
Has anyone had such an issue and have you solved it somehow?
There are other issue, like hints not working on a XE8 project converted to Seattle on Windows. It was mentioned in this question Firemonkey Hints don't work in Delphi Seattle, for a project converted from XE7. I fixed that by recreating the dproj file and it probably has something to do with the default manifests/themes.
Also hints for controls placed on a TLayout don't show, because the layout doesn't have the ShowHint property. Doesn't sound very logical to me, but at least it can be overcome by setting each control's ShowHint property manually.
The issue is reported on QC as RSP-13218
After more tracing through FMX.Forms I found the bug.
In the end of the TCommonCustomForm.Create method the hint object is set with
if not (csDesigning in ComponentState) then
FSharedHint := THint.CreateNewInstance(Handle);
but when the BorderIcons are changed, and also in other cases, it calls the TCommonCustomForm.Recreate method, which also recreates the window handle, so the hint is no longer linked to it.
To fix it I had to also recreate the hint by adding a few lines before the finally clause in the Recreate method:
if Visible and ([TFmxFormState.Showing] * FormState = []) then
FWinService.ShowWindow(Self);
// Added lines
if not (csDesigning in ComponentState) then
begin
FSharedHint.Free;
FSharedHint := THint.CreateNewInstance(Handle);
end;
I support an old (late 90s) Domino DB that has a growing number of Mac users. In some docs, layout regions become grayed out once you click anywhere in the doc even though it's still editable, i.e. if the cursor was in a text field and you type something blindly and save it, it will be there when you reopen the doc. It doesn't happen in all docs and I have found no pattern.
Any Domino designers seen any behavior like this? I don't this there is anything too weird in the code; onBlur or onChange used in some cases - that sort of thing. Nothing too complicated really. Thanks!
Layout regions are a nightmare to maintain: there can be objects with differing hide-when formulas stacked on top of each other that might be causing this. I suggest making a copy you can work in without worry: inspect each object fully (keeping notes) then delete. Keep drilling down until you hopefully hit an object that matches your grey-out. If you don't find one, then it could be a bug as posted by Richard Schwartz. As Richard and D.Bugger suggest, perhaps it's time to rebuild the functionality without using a layout region: layout regions never worked with a web browser.