According to System.pas, it is documented as True if compiled as console app. In System.pas, there is also an assignment
{$IFDEF LINUX}
IsConsole := True;
...
I have a strange problem where an app is launched from a Delphi app, using ShellExecute, and then it runs into this code, raising the (unexpected) exception
if System.IsConsole then
raise Exception.Create(Msg)
The application is not compiled with Project/Options/Linking/Generate console application. What else could set IsConsole to true?
Note that in Delphi XE2, OSX applications can not use this variable as it is always true. See QC Entry 98956 and Why Does My OSX FireMonkey App Think It Is a Console App ?
Found it: the executable has been created using dcc32.exe and the dpr / cfg file, the cfg contains a line
-cc
which creates a console application.
The Delphi 2009 Enterprise IDE does not show this setting in the Project/Options/Linking/Generate console application dialog. The application was ported from an older Delphi version and maybe something went wrong over the years.
Related
It is probably me being stupid, but I am having problems detecting if a network drive is up, but only when running the program in the IDE – when running the program outside of the IDE, the network drive is correctly detected. The IDE works fine on Windows 7.
While the program in question is different, I can reproduce the issue by creating a new project and adding the following into the Forms OnActivate event:
var
bRet: Boolean;
LTemp2: string;
LFreeSpace: Int64;
LTotalSpace: Int64;
begin
LTemp2 := 'T:\';
bRet := GetDiskFreeSpaceEx(PAnsiChar(LTemp2), #LFreeSpace, #LTotalSpace, nil);
ShowMessage('GetDiskFreeSpaceEx: Drive T: is up? '+BoolToStr(bRet, True));
end;
Assuming I have a networked drive T:, if I run the program in the IDE then the above always returns False, but if I run the built program from a desktop shortcut then it returns True. I get the same behaviour if I run it via a button click after the program starts. Doing DiskSize() and FindFirst() on the root directory give the same results.
It is a clean Windows 10 install, not an upgrade, with a clean install of CodeGear 2007 with all the patches applied. I have tried “Run as administrator” and all the Compatibility Modes back to Windows 7.
Am I doing something stupid?
After R. Hoek's great insight, and while it does not fully sort out the issue, it is at least enough for a workaround. By the way, at least in my case, it does not matter if I launch Delphi 2007 with "Run as administrator" or not.
I added a TOpenDialog hooked up to a button: once I run this and select a file on T: then GetLogicalDrives() works fine.
So what I now suspect is that I installed Delphi 2007 as an administrator - not sure how, but I think I will re-install everything.
Even if that does not resolve it, and since it only occurs in the IDE and not in production usage, I can add code to pop up a TOpenDialog if GetLogicalDrives() returns 4.
Weird. Thank you all very much.
By the way, one aspect of this discussion may not have been clear: Delphi 2007 was running under the user account (and it could see the network drive without problems) - it is only the program which is being debugged that cannot see the networked drive. That is why using the TOpenDialog resolved the issue (until Delphi or the computer was restarted).
I am using Delphi 7.
TOpenDialog.Execute hangs the program if launched from the standalone
EXE.
When the project is executed from Delphi 7 it does not hang.
It does not matter what I add, even a blank project with a button
that has OpenDialog1.Execute on it will cause the hang when clicked.
This problem is recent. Projects compiled before a while ago do not have the hang.
I used the same Windows installation (Windows 7 Ultimate 64bit) and
the same Delphi 7 for years now.
Projects compiled before a while ago do not have the hang.
Projects from Delphi 7 that are complied in Delphi 10 will also cause the hang.
It does not happen in CLX applications, whether in debug or standalone.
Here's an example of what seems to be causing the hang:
procedure TForm1.Button1Click(Sender: TObject);
begin
OpenDialog1.Execute;
end;
Update:
Cause might be "InitialDir" being the Desktop. If it's set to c:\ for example, it won't happen.
Another thing to look at is Project -> Options -> Compiler Messages (are there any unchecked?) If so, those are exceptions begin ignored by the IDE's built-in debugger. Check them, and run, then you might see what is causing the hang-up.
The only time I have been able to produce this is when I have a network share that is sluggish or not there... during the IDE debugger it timesout and keeps going, however, standalone it will eventually timeout, but, much longer.
(Most likely it is something in your Project -> Options screen). As I do strange things that most people never do :-) (sshfs for example will cause this).
I once had this problem in some of my application if i wanted to access network shares. By including the compiler switch
{$SetPEOptFlags IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE}
I could get rid of the problem. See also this blogpost. But be aware, that this switch has some restrictions.
As Microsoft mentions, "The /TSAWARE option is enabled by default for Windows 2000 and later, for Windows and console applications", meaning every .NET application has this switch turned on by default.
I have a Delphi program which runs on Microsoft Windows (English) environment, but fails when running in a Windows (Chinese) environment.
The error message is:
Exception EReadError in module rtl160.bpl.
Error reading Button2.Click Invalid property Value
However, the "Button2" has a valid OnClick event method.
I have several other similar Delphi programs which run in both environments. I haven't spotted what is different about this particular program.
Anyone else run into this sort of thing? Where are the best areas to look?
I have an application written in Delphi 7 which uses a c++ dll written in BCB 5.
I want to debug this dll from the Delphi IDE is this possible?
If it's possible which are the steps to debug?
As additional information I have the full source code of the dll.
It has been a while since I have dealt with C++ / Delphi together. But if I remember correctly, you can use the BCB IDE to run the Delphi application (compiled already) that uses your DLL. Basically, in your project settings in BCB, you can set a program to run when you click the "run" button, and I believe that you will be able to set breakpoints and stuff that will be caught when functions of your DLL are being called by that application. Still, this implies that you have BCB.
My recollection, and it's been a while since I last tried this, is that you need the C++ Builder IDE to do this.
It should be possible:
I have done it quite often to debug a BCB5 dll within the Delphi 6 IDE. My delphi 6 application uses the DLL and I can then step from the delphi code into the bcb code (and back). So I might work with Delphi 7 too.
Delphi isn't configured by default to do that. At that time I found an explanation on the web how to do it. Not sure, but it might have been the following page: http://www.delphifaq.com/faq/delphi/delphi_ide/f178.shtml
You will also need to compile the dll in debug mode and to indicate the path to the source code of the dll in the project options of your delphi application.
I've been working for a long time under Windows XP with Delphi 6 (and under Win2k before).
As I've recently bought a new laptop, I had to start using Windows Vista.
I've installed Delphi 6. Whenever I used the TBitBtn component, I get error when running the compiled program: like resource BBOK not found, resource BBcancel not found, etc.
"Project Project1.exe raised exception class EReadError with message 'Error reading BitBtn1.Kind: Resource BBCANCEL not found'. Process stopped. Use Step or Run to continue."
Right now, I do not have possibility to try to run the exe-file on WinXP; however I was able to compile the same code under WinXP and the produced executable ran fine under Windows Vista as well.
Is there some simple workaround other than upgrade to a newer version of Delphi?
Thanks in advance!
This is definitely not a very neat solution, but this issue seems working after:
Copying Buttons.pas and buttons.res from Sources\Vcl to the directory with my project.
Editing Buttons.pas to use QBOK, QBCANCEL etc. instead of BBOK, BBCANCEL.
Thanks for your comments.