I'm trying to work on a personal project at home using the free Delphi RADstudio 10.2 on my Mac thru VMware Fusion running Windows 8
I can't access any of the most used keyboard shortcuts :
CTRL + mouseClick : to go to the signature of the method
CTRL + Shift + C : to create/insert the implementation part of a method's signature
CTRL + Shift + F : to search within my project | a directory
I've tried Malcom Groves' advice: disabling keyboard shortcuts from mac OS host ('RAD Studio/AppMethod keystrokes vs VMWare Fusion Unity View', http://www.malcolmgroves.com/blog/?p=1716) to no avail ...
thanks for your inputs : solving this minor annoyance will speed up the project
Related
I'm using Mac+ a VM and I would like a shortcut equivalent to f5 on a PC so that I'm able to speed up my workflow.. Thanks!
f5 does nothing (can I map it somehow?)
Command + f5 doesn't work either.
If you want to use the same keyboard shortcuts as for Visual Studio on Windows, open Preferences - Environment - Key Bindings and select 'Visual Studio (Windows)'.
Note that F5 Debugs the project.
You can also configure keyboard shortcuts on this page.
I've noticed that after some Windows update, my application made in Delphi 7 does not focus correctly anymore. The title bar does not change color. UI elements like buttons, scrollbars, etc do not react. I also can't minimize or close the Form with the titlebar buttons.
What is weird is that I can still move the Form around by dragging the titlebar, and the program is working fine in general.
Here is an animation showing what is happening:
Here is the list of Windows versions I've tested on:
Windows 7 SP1 + updates -> OK!
Windows 8.1 without updates -> OK!
Windows 8.1 with all updates -> NO FOCUS!
Windows 10 BUILD 10240 -> OK!
Windows 10 BUILD 10586 -> OK!
Windows 10 BUILD 14393 -> NO FOCUS!
I tried disabling Window Ghosting with this code:
var
User32: HMODULE;
DisableProcessWindowsGhosting: TProcedure;
begin
User32 := GetModuleHandle('USER32');
if User32 <> 0 then
begin
DisableProcessWindowsGhosting := GetProcAddress(User32, 'DisableProcessWindowsGhosting');
if Assigned(DisableProcessWindowsGhosting) then
DisableProcessWindowsGhosting;
end;
end;
Also, I removed all Application.ProcessMessages() calls, but still no change.
It turned out that this odd behavior was caused by code in TForm1.Activate.
Looks like that putting too much complex code in that section wasn't a good idea.
I've moved whole code to TForm1.JvTimer1Timer and now problem is gone.
I'm migrating from XP to Windows 7 64 bit. My app which I compiled on my XP machine works properly on XP. However when I run the exe on my W7 machine, the list of voices returned by GetVoices is as follows:
Microsoft Anna
Microsoft Mary
Microsoft Mike
Sample TTS Voice.
Checking the W7 Speech Properties dialog shows that only Microsoft Anna is loaded on the machine. Checking the registry at HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Speech/Voices confirms this.
Recompiling my app on my new Windows 7 development machine creates an exe that duplicate the above behavior. (The XP compiled code and the W7 compiled code reproduce the same error when executed under W7)
I'm developing in Delphi 7 on Windows 7 64 bit and I'm using the Microsoft Speech Object Library (Version 5.4) (note: 5.4 is what shows in the Import Type Library list).
I installed SpeechSDK51.exe onto my W7 machine. This came from:
http://www.microsoft.com/downloads/details.aspx?FamilyID=5e86ec97-40a7-453f-b0ee-6583171b4530&DisplayLang=en
The following code produces the list of 4 voices on Windows 7 even though there should only be one voice:
procedure TForm1.FormCreate(Sender: TObject);
var
i: integer;
SOToken: ISpeechObjectToken;
SOTokens: ISpeechObjectTokens;
begin
cbbVoices.Clear;
SOTokens := SpVoice1.GetVoices('', '');
for i := 0 to SOTokens.Count - 1 do begin
SOToken := SOTokens.Item(i);
cbbVoices.AddItem( SOToken.GetDescription(0), TObject(SOToken) );
SOToken._AddRef;
end;
end;
Any suggestions on how to deal with this problem?
thanks,
shawnh
Microsoft Anna is the only 64-bit voice you have
the other ones are 32-bit engines.
Your system can only use the 64-bit engine(Anna) so only this one can be selected in the panel. But the other ones are installed as well. If you open this file: /%Windows%/SystemWOW64/Speech/SpeechUX/sapi.cpl you will see a dialog similar to the one for the control panel but now you will be able to select any one of those voices as the standart voice.
Unconfirmed yet, but I think that Microsoft Sam, Microsoft Mike and Microsoft Mary do not work on Windows Vista and later.
I guess you could install them with the 5.1 SDK, so they are reported back when you query the voices, but being possibly not compatible with the 5.4 engine, they cannot be used.
You may want to filter GetVoices with the EngineProperties attribute to limit what is returned.
Disclaimer: all this is untested/guesswork/doc-reading....
On my Windows 7 system, the GetVersionEx Windows API function returns "6.0", indicating Windows Vista, when it should return "6.1".
If it matters, I used the following Delphi code:
function winver: string;
var
ver: TOSVersionInfo;
begin
ver.dwOSVersionInfoSize := SizeOf(ver);
if GetVersionEx(ver) then
with ver do
result := IntToStr(dwMajorVersion) + '.' + IntToStr(dwMinorVersion) + '.' + IntToStr(dwBuildNumber) + ' (' + szCSDVersion + ')';
end;
and the string "6.0.6002 (Service Pack 2)" was returned.
Isn't this highly odd?
I now found that GetVersionEx returns Vista when my application runs through the Delphi 2009 debugger, but Windows 7 when the application is executed alone. I also found that RAD Studio (the Delphi IDE) actually runs in compatibility mode for Windows Vista SP2. Hence everything makes sense, for, as pointed out by kibab, a child process will "inherit" the compatibility settings of its parent process.
Is your executable running with any compatibility settings defined (I assume this might be the case for legacy Delphi applications)? The documentation of GetVersionEx states:
If compatibility mode is in effect, the GetVersionEx function reports the operating system as it identifies itself, which may not be the operating system that is installed. For example, if compatibility mode is in effect, GetVersionEx reports the operating system that is selected for application compatibility.
Maybe GetProductInfo can do what you want?
I think it may just be you. i.e. your D2009 may have been marked by windows, as needing to run in compatibility mode.
I made a test app with your function, and compiled and ran both with D2009 and D2010, inside the debugger and externally (click the exe in windows explorer), and for all 4 cases, it came back with: 6.1.7600 ()
Running on Windows7, 32-bit.
So I have Visual Studio 2003 running on Windows 7 - yeah I am aware it isn't officially supported - and no, unfortunately I can't change that situation :-(
For the most part it works OK but I have a specific problem, that I can't figure out. The application hangs if you do a project wide search (Ctrl - Shift - F) for a string.
I have a reasonably powerful machine and all the other heavy tasks like compiling and debugging all work fine. It also works if I restrict the search to the current document (Ctrl - F). I am running it as administrator and VS.NET 2003 SP1 has been applied.
The size of the project does not seem to be a problem since a colleague is also experiencing this issue for a single project solution containing 5 pages.
I am currently using Windows Search as a work-around and I was wondering if there is something I missed that I should try.
Try disabling the Aero theme in compatibility. Yeah seriously...
You can do this by right clicking the shortcut to launch VS.NET 2003 and selecting properties, choosing the “Compatibility” sub-tab and then checking “Disable Desktop Compositing” as well as “Disable Visual Themes”
I use Windows 8.1, and the path
[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
is invisible and could not be created manually inside regedit.exe.
So I wrote a registry file "abc.reg" with text:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Microsoft Visual Studio .NET 2003\\Common7\\IDE\\devenv.exe"="^ RUNASADMIN DISABLEDWM DISABLETHEMES"
Execute it by double click icon of "abc.reg" (may be Run As "Administrator").
It works.
(The post is for your convenience in this certain case)
I am running Windows 10 Enterprise 1909 and found global search also causes VS2003 to freeze and stop responding.
The advised registry edit did not work for me - VS2003 refuses to start up when run as admin:
A referral was returned from the server.
This is the same error I get if allowing the compatibility trouble-shooter to apply Windows XP (Service Pack 3).
I can get global search working if I remove RUNASADMIN and DISABLEDWM from the registry value (I.E. leave only DISABLETHEMES in place).
Create a registry key as follows:
Location: HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
New: String Value
Name: C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Common7\IDE\devenv.exe
Value: ^ DISABLETHEMES
You will end up with an even uglier UI (quite an achievement in itself!) but at least global search will now work.