Compiling a rather large project (>750K lines) with delphi XE3 (upgrading from 2009)
Getting the following error
[dcc32 Fatal Error] MainForm.pas(3170): F2084 Internal Error: URW1147
Similar to this question, however nowhere in the code are generics used.
internal error with generic array
The error does not correspond to a line of code, but rather just the end of the file.
I.e. after the "end."
Following a google search I have also tried all settings for "Code inline control", but no joy.
Not sure where (else) to start looking and would appreciate any educated feedback (or maybe even a wild guess).
Have not yet put in a QC report pending hopefully usefully feedback from here.
Thanks
Have resolved this issue by stripping back the code a section at a time as per David's suggestion above.
Solution is was follows in case this is helpful to anyone...
Turns out there was a 'left over' fragment of 'generics' code which was thought to have been removed several years ago and replaced using more traditional techniques.
There was single local variable which was not refactored, defined as follows.
var
TestProc: TProc;
when assigned as per the following, the internal compiler error is triggered (however nowhere near the offending line of code).
TestProc := TestSuite.TestProcs[i].TestProc;
The array element TestProc above is of type procedure of object.
This compiles (and works perfectly) under 2009 which was why it wasn't picked up earlier, but gives an internal compiler error under XE3.
Correcting the local variable declaration (to procedure of object) fixes the problem.
Related
I'm trying to connect my Windows XP program (Lazarus) to my Ubuntu postgres server.
When the Lazarus program runs, it seems to compile fine but I get this error:
Project ... raised exception class 'RunError(211)'.
Then it terminates execution (and I don't see any output), and opens up a file customform.inc. In that file, it shows a procedure procedure TCustomForm.DoCreate; where it highlights a line: if Assigned(FOnCreate) then FOnCreate(Self);
I believe this is one of the system's files.
I never get to see any output.
What could this be? Thanks!
MORE INFO:
I've narrowed down the error to this line:
dbQuery_Menu.SQL.Text:='Select * From "tblMenus"';
dbQuery_Menu.Open;
the exception is triggered when the OPEN statement gets executed.
BTW, dbQuery_Menu is defined as a TSQLQuery component.
Clueless! :(
Run error 211 appears when you try to call an abstract method. Check this link from more information on FreePascal/Lazarus runtime errors.
Since you say all is done by code and you have no visual components, the problem probably lies in your code trying to use an ancestor component which has not overriden the Open method. You should be able to solve this by using the correct descendant component.
Another possibility, although I would strongly recommend to avoid this one, is to override the Open method yourself. It should be avoided because if you are using an ancestor component then you probably would have to override more abstract methods.
HTH
After nearly 5 days I found the answer. Many thanks to all thos e ho have contributed with their ideas ESPECIALLY RRUZ, RBA and Guillem Vicens. there are other related posts all connected to getting the FIRST Lazarus program working with PostgreSQL.
Summary.
The biggest mistake I made here was that I used the TSQLConnection component. Don't do this. Instead use the TPQConnection.
Everything is done through code. We're not using any draggable components from the top tab.
Don't rely on the Lazarus docs (wiki) at least for working with PG DBs.. It is outdated. Some of the examples can be pretty misleading.
Make sure that fields have some default values. For example, if a Boolean field has no true or false (t/f) set, this may lead to errors.
And that's it! I hope many postgres+Lazarus newbies will find this useful.
From here - http://www.network-theory.co.uk/docs/postgresql9/vol2/SQLSTATEvsSQLCODE.html - -211 (ECPG_CONVERT_BOOL) This means the host variable is of type bool and the datum in the database is neither 't' nor 'f'. (SQLSTATE 42804)
When using the following line code in Delphi 2010, a'm getting an "Access Violation" error, but the same code working fine in VC++.
The Delphi 2010 code is
var
hMyInf : HINF;
begin
hMyInf := SetupOpenInfFile('.\\DIGIMHID.INF','Mouse', INF_STYLE_WIN4,Nil);
The VC++ code is
hMyInf = SetupOpenInfFile(".\\DigimHID.inf", "Mouse", INF_STYLE_WIN4, NULL);
Please help me to solve this issue.
Thanks All.
Call LoadSetupAPI before using any methods in the SetupAPI.pas
Edit, to provide some background: As simultaneously wrote by David in his answer and by me in my comment, the error is probably caused by calling an uninitialized method pointer. For me the first tip was the error message, an Access Violation: If the equivalent of an Access Violation came from Windows itself, it'd be called a Runtime Error 216. The code is very simple, only uses constants and a method call. Constants can't generate AV's so the error had to come from the method itself, or from calling the method.
Since the Delphi declaration supplied showed a "function type", I suspected SetupOpenInfFile is actually an method pointer, not an import method. Those pointers need to somehow be initialized. Searching SetupAPI.pas (thanks google for providing a link, because I don't use JEDI libraries) I quickly found that it's being assigned from LoadSetupAPI. My first thought: isn't LoadSetupAPI called from the initialization section? It's not, so it needs to be called from code. Problem solved.
Your filename is wrong in the Delphi version. You don't escape \ in Delphi, a single one will do. But that wouldn't lead to an access violation.
My guess is that your GetProcAddress call is failing. But that is a guess. I'd like to see more code and the full error message.
EDIT
It seems that we were on the right track. Cosmin's answer will solve the problem for you. An alternative would be to switch to inplicit linking by removing the definition of the condition SETUPAPI_LINKONREQUEST in SetupApi.pas.
I was able to build one application up to this morning, then I don't know what happened as I try to build I have
[DCC Error] myunit.pas(1710): E2056 String literals may have at most 255 element`
Why this if this was working? (1710) was not edited in last month. I checked with a colleague project options and environement options one by one and they are the same. (the only difference is that i installed all Delphi updates, while he didn't anyway I didn't install them today).
moreover if I fix the above "erroor" by splitting the string in 2, doing something like
S := 'firstpart' + 'secondpart';
instead of
S := 'firstpartsecondpart';
// this is an example of course firstpartsecondpart
//is a string of more than 255 chars
I have another problem:
[DCC Error] myunit.pas(1797): E2283 Too many local constants. Use shorter procedures
Why this? I didn't change this procedure today. It is a long procedure indeed, but it used to compile up to this morning. I tried to split tjhe procedure in 2 and I was able to compile...
And Finally...
Breakpoints doesn't work anymore. If I try to set a breakpoint, after compiling and linking the RED cirlce of breaxpoint becomes green with an X, like when you try to debug a line of code that cannot be debugged.
I tried all, including rebooting and setting Debug Info to True in project options.
FINAL NOTE: It seems that for some reason some strange settings have been applied. I can't recall having done something strange. Recently I installed CnPack, but I could use it effectively for days. This problem started today.
Can anyone give me an hand? I am in real trouble, I lost half day and I still don't see a way out.
It seems you've changed the "Huge strings" project option. Did you add a {$H} to your code? Or did you fiddle with the project options? ("Compiler options/Huge strings" need to be checked to default to strings longer than 255 characters.)
The green breakpoint thingie means that this specific code is not compiled, thus it will not be called. Check if your code is calling this code, or perhaps it's looking at some other (pre-compiled?) unit.
My comments from below to complete the answer:If all breakpoints are green, it appears you have a problem setting the project options. If you remove the YourProject.dproj and YourProject.dproj.local files (Move somewhere else, don't delete) and then open the YourProject.dpr, your project should have the default options. Check if it works in that case. If not, move the old files back.The E2056 error is because strings inside Delphi code cannot be longer than 255 characters. Splitting it by including '+' in your string can fix this. See qc.embarcadero.com/wc/qcmain.aspx?d=71575 for why your collegue doesn't get this warning.
I am using Delphi 2007 with all patches and updates.
I have a file which is used by two different projects. In that file is a procedure, which I will simplify as follows:
procedure MyProcedure;
const
UniqueValue: integer = 0;
begin
//some code
Inc(UniqueValue);
//some more code
end;
The Inc() command should fail, because you cannot assign to a constant. In one project, I get an error to that effect (I'll call that project "Accurate"). In the other project, I don't get any errors (I'll call it "Bogus"). I also don't get any warnings. I can't figure out why the compiler lets this incorrect code through.
Here's what I've tried in project Bogus:
1 - Introduce an obvious error, like typing "slkdjflskdjf" in the middle of a line
Result: I get an error,which proves that it is really trying to compile this file.
2 - Delete the .DCU, and rebuild the project
Result: The .DCU is re-generated, again proving that the project is truly compiling this erroneous code.
Does anyone have thoughts on why this behavior would occur? And more specifically, why it would occur in one project but not another? Is there some obscure compiler option to permit assigning to constants?
One final note: Both projects are converted from Delphi 5. Under Delphi 5 with similar code, they both compile fine.
Edit: Thanks for all your help. After changing the assignable typed constants directive, I can get consistent behavior across both projects. I learned something new today...
There is an option for this called "Assignable typed constants" in Compiler Options. It can also be enabled with "{$J+}" in your code.
Could it be that those projects differ in the setting of the $J compiler directive?
I'd suggest to check the Project Options, section Compiler and see if you can spot any differences. Maybe you have option Assignable typed constants enabled in the Bogus project.
As others have said it's almost certainly the {$J+} directive.
If you have a diff tool you can compare the project files to see how they differ - they're just text files - to solve similar problems in the future.
I'm getting the error: wintypes.dcu not found several times a day in the Delphi 2009 IDE, after this error code completion stops working, also I can't open any unit's source code with Ctrl + Click, then I have to reopen the IDE to fix it.
Anyone has a clue about what can be causing this?
The only IDE extension I have installed is GExperts.
wintypes.pas and winprocs.pas has been replaced with windows.pas (since a long time). You should use Unit Aliases to replace all wintypes with windows.
You must be still using the ancient (pre-Delphi 2) names for what is now the Windows unit. I recommend that you search and replace all your uses lists and replace WinTypes and WinProcs with Windows.
Alternatively, you can make sure you have "WinTypes=Windows" and "WinProcs=Windows" in the Unit Aliases section of your project options, but still, after all these decades, I'd move on to the 32-bit world! (16-bit being the prime limitation that meant WinTypes and WinProcs were two separate units.)
Open Project - Options, Delphi Compiler ,into Unit aliases insert:
WinTypes=Windows;WinProcs=Windows;DbiProcs=BDE;DbiTypes=BDE;DbiErrs=BDE
Do you use the Decision Cube component? So look for references on the unit MXQEDCOM.pas in your sources.
On BDS 2006, is the only reference for Wintypes and Winprocs I found.
By the way, make sure that the Unit Aliases included the values that Barry Kelly wrote.
Why wintypes.dcu cannot be found any longer, I do not know. But the other two are obvious follow up errors: if Delphi cannot compile the code due to syntax errors (and a missing file is considered a syntax error), it stops code completion and cannot locate source code any longer using Ctrl + Click.