I have done all the searching and can't find a solution to this weird problem that's been bugging me for about 5 hours. I started this app in Lazarus, but then took it across to D5pro to see if I could solve the problem. Thought it might have been a Lazarus "thing."
In D5, I have an app fully-working (so far so good) and I decided to try some different approaches to the look and feel so I "Save Project As" into a new folder. I then went through all of the included Units and saved them to the new Folder. I copied the two OpenSSL .DLL to the new folder. Did a compile and run and it all works fine. Well, almost.
When I tried the new app, the POP3 Unit crashes at "Login"
I have stepped through and all of the basic login stuff, Server, Name, SSL parameters etc is identical to the former version.
I went back to the original app and did a full Build and it still worked fine. I did a full Build on the new app and it still crashes at Login.
It gets through the pop3.Sock.SSLDoConnect() OK, but comes back from pop3.Login() with an error 10061 which according to the BlckSock Synapse-Unit, means "Connection refused."
When it returns from this call Result:=ssConnect(s, #name, SizeOfVarSin(name)); which I assume is in the .DLL it has a Result of -1 which then triggers the GetLastError and that is "10061 - Connection refused"
As far as I can find, everything is identical between the two projects. All Library Paths are in the Environment and not within the project.
Any thoughts and suggestions?
There is not much to work with. Can you see all parameters in the debugger on the various external call moments?
A change of compiler of course can make hidden bugs come to the surface, just like e.g. optimization. A well known difference is that the life time of temps might vary (see here).
Probably you need to nail the defining difference first. As with Delphi, the debugger is your friend here.
OK, problem solved.
Sir Rufo, it was a good idea but it did not help, but thanks for trying.
I had copied the ssleay32.dll into the new app folder BEFORE I started compiling. It did not work. I did a full Build and it still did not work.
I decided to delete the ssleay32.dll and libeay32.dll and do a full Build. I ran it and of course it crashed, but this time I expected that.
I then copied the two .ddl back into the new app folder and did another full Build.
Bingo problem solved. Seems weird but it is working with both Lazarus and D5. Something to do with the way the .dll gets linked into compiled .dcu.
Doing the Build with no .dll available cleared that. Dropping the .dll back into the Folder and another Build got the .dll linking correctly included into the .dcu.
Aaarrggghhhhh :)
Related
I built an electron app that allowed dragging files in, with a jQuery script that just takes some info from that (path) and adds an li to a list. That's it. It worked great.
Then I followed this guide, because the next step is to send that information to a python script that analyzes the files (maybe relevant: when installing zeroRPC I built from sources, didn't rely on the prebuilt fork that's available there).
Now I get this crazy bug where when I drag files into the app my mouse pointer changes to not-allowed and the drop event doesn't fire. It's so weird.
I don't have any code sample to give because I can't really tell which part is wrong. The only changes I've done are the ones in the guide I linked, and they have nothing to do with the front-end. I'm really confused by this. not-allowed? Why?
Well, as suspected, the issue had nothing to do with either the front end or the back end. None of my code, really. It turned out that since I needed to compile some stuff while preparing zeroRPC, I used powershell as an administrator,, and you can't drag files from user-run explorer into an admin-run electron app - which makes sense and is in fact an expected behavior (it just so happened that I encountered this after doing some work, causing me to think the problem was with something I changed in my code).
I recently changed operating systems on my laptop (went from 8.1 to Windows 7). I transferred my game project, and after having to rebuild it (due to Visual Studio 2013 stating it cannot open my project file), I managed to get it to run, but as soon as the code tries to load my cube.fbx model, I get the error in the title.
My settings for the model are as follows:
And the code for loading (which worked flawlessly before the transfer) is as follows:
modelCube = content.Load<Model>("Models/cube");
I have no idea what the issue is. All help points to setting the Build Action to "Content" and the Copy to Output Directory to "Always". The only clue I can think of is that originally, my project was made for Android, and on this iteration I remade it as a normal Windows project (as for whatever reason, I couldn't get an Android project to work this time).
Thanks in advance. This is really confusing.
While I doubt anyone else will have this problem, I figured out the issue. I think Monogame changed the way it loaded assets since the last time I used it. With my install of a newer version, I just had to follow the link below to get it working again.
http://rbwhitaker.wikidot.com/monogame-managing-content
When I compile a project in XE8 (with update 1), I get frequently a error that a file is missing, although the file is just available. And when I compile again, it is another file that is missing. It seems random. After a few compiles (sometimes more or less) I have build the project. And even at Run (F9) I sometimes get the error that a file is missing.
Like #Andrei Galatyn said at the end of his post, it will be solved when you delete your Android configuration in SDK versions. But I want to be able to develop with Android. What is the real problem?
I couldn't find a solution on the internet yet.
Is there a solution for this problem? Thanks in advance!
I have similar problem with Delphi XE8/XE7 at least at 3 different PCs (home PC, notebook, VMW-based virtual machine in office). All PCs are fast, all are SSD-based. Usually i get the error message when trying to build large project, for small projects errors are very rare (but happens time to time anyway). So i am quite sure that it is problem with Delphi. What i tried:
added src/dcu paths as exception to antivirus
disabled indexing of files in Windows (Windows 7 x64/Windows 8.1 x64)
deleted all SDKs for mobile development in IDE (this step was most usefull in my case).
It doesn't solve the problem for 100%, but now i see that random message only few times per week. I will be glad to see real solution.
Just for information - many errors like "file YYY\XXX.pas not found" where with wrong path to the file, it was path somewhere inside of Android SDK. After deleting of all SDKs (fortunately i need only with Win x32/x64 platforms) i never see such errors anymore.
Some time ago i sent it to my colleagues:
Many times i got an sporadic error in Delphi IDE like this:
F2039 Could not create output file '.\dcu\FireDAC.Comp.DataSet.dcu'
When I just tried to compile again, the problem disappeared but compilation may fail on another file. It was especially annoying when I need to rebuild an large project, for example <...>. Finally I discovered that under some conditions Delphi is trying to access files at wrong path:
C:\Users\Public\Documents\RAD Studio\12.0\PlatformSDKs\adt-bundle-windows-x86-20130522\sdk\tools\dcu\FireDAC.Comp.DataSet.dcu
Instead of
C:\M2014\Fellesressurser\felles\FireDAC.Comp.DataSet.dcu
All the time when I get the error it was try to access Android SDK folder instead of my application folder.
If you experienced same problem, you can solve it now, just delete Android SDK from Delphi IDE:
Open “Tools\Options\Environment Options\SDK Manager”
Select installed SDK (list “SDK versions”)
Delete it (button “Delete”)
I've got a group project built in Delphi XE2 that has 3 projects that always build to the wrong folder for one option set. (I've got 4 configurations under Release and Debug, one for our software configurations and one for FastMM and it's only the debug one that I want to use for debugging that always goes in to the wrong folder. Compiling the project even says it's building to the correct folder, but the DLL always winds up in a different one which I only used once when I was unit testing the code outside of the main project.
I've deleted every associated file, .identcache, .res, .tvsproj (whatever that was) and nothing changed. One very strange thing I noticed is that I copied one of the projects to configure the second one and mimics the behavior of the one it was copied from and I never even unit tested that one, so it never had that output path configured for it.
Obviously this makes it pretty annoying to debug, I have to copy files in to the correct folder just to do that (I was kind of astonished when it actually worked, because I thought Delphi might expect to find the files in it's output path, but oh well, those things are magic)
Let me know if I can post anything to help, I don't really know what's necessary, I checked the registry for the output path that it is getting built do and found nothing that I thought was of any consequence (nothing related to these projects).
One thing I did notice was, because I copied the original project into another project (they're plugins to the same part of the main program) it has the same and when I try using it in the "Build Group" it automatically selects both projects. That's one mystery solved, but is probably a red herring?
OK so as usually happens, after 3 years of suffering with this when I finally ask the questions I'm lead straight to the answer it appears as if RAD Studio is lying to us. The configuration shows this:
but the dproj had this:
in it.
there were two conditions for cfg_3 and only the last one showed up in RAD Studio, well for some odd reason the build path was taken from the first one (even though it's specified in both). So, removing the wrong one (the first one) fixed the problem and things are now building to the correct folder.
I had imported the Utils option set when I was testing the library, but when I incorporated the program in to the main program, I removed it. Somehow it didn't find it's way completely out of the dproj and I guess (not sure why) but it seems like the other library got messed up because it shared a GUID.
I'm having some kind of problem with my project that me and my friend is working on. When I try to open the project that I've been working on it gives me an error message saying that "one or more lines were too long and have been truncated" and thus I can't see my code or GUI. When my friend opens the project on his computer (The project is on dropbox so it's the same file) there's no problem at all. I've googled but couldn't find anything. I just did a repair of RAD Studio but no luck. We have 2 forms and a unit that we use, the unit and the mainform isn't working for me but the second form is no problem.
Thanks!
Make a copy of your project directory.
Search your harddisk for XXXX.pas and XXXX.dfm
Hopefully there will be some temperary files that match - like "mylostform.dfm.~1307~" . copy the newest to your project directory, and rename them to "mylostform.dfm" and "mylostform.pas".
Kind regards,
Geir Bratlie
From the comments, you have Dropbox, and the Restore functionality is available, but using it would cost you a week's worth of work.
If I was in that situation, here's what I would do:
Copy the current file to somewhere else (My Documents, for example).
Use Dropbox Restore to get the old version that works.
Make a copy of this, because you're going to be modifying it
Ensure that you can open it in the IDE.
Use Beyond Compare to open the two files side-by-side. (If you don't have this, you really should!)
If they're completely different from each other, you have a serious problem. If not, you'll see the changes you've made. Start copying changes one at a time, and after each change, save and try to open it in the IDE.
At some point, you won't be able to. That's where your problem lies. Now you can fix it!