I have a form with some controls that are positioned with the Anchor Property.
I Debug AND Release Mode it works fine, but when I copy the .exe to another place and execute it there it fails.
This only happens for this one special form, all other forms of the project work... I hope that someone ran into that earlier
EDIT: It's bad said: The anchor positioning does not work properly
I found it and I post it here in case someone else is also trapped by that:
Copy all resource dlls and everything else that is produced by the Compiler along with the .exe
Related
I am attempting to build a custom lookup in exim, I have followed the docs and good the groundwork in place so my additional code is being compiled and hooked in, as well as being called. I am using the Makefile included with Exim to perform the build and I have added in CFLAGS=-g -O0 to ensure I have debugging symbols.
Codeblocks, gcc, gdb and the source all live on my Linux box, which I am SSHing into and exporting the X session to my Windows desktop using XMing, I don't think this has any baring on the problem, but worth mentioning.
Now, my problem is that when I run debugger with breakpoints in, C::B seems to be not setting or gdb is ignoring breakpoints in my code, but is hitting ones I have in the main function (I added one at exit so I could read the execution output and to prove they were working).
I have confirmed my code is actually being called, it currently spits out an error message, which it is doing. If I add a breakpoint on that line, it doesn't fire, nor if it's on the function or first line of the function.
What is even stranger (to me), is that previously it was working! it only stopped working when I resized the bottom C::B pane which caused a portion of the screen to not render (I think this is a problem with C::B and XMing, sometimes I just get a grey blank window and need to stop and restart C::B). So I quit C::B, restarted it, reloaded my project and since then break points in my code simply do not work, even though I can prove the code is being executed.
Also if I manually add the breakpoint it works as expected. I set a breakpoint in C::B at the start of main. Hit debug and then sent b mddfind_open (name of my function) into gdb and hit continue.. C::B stops again at the start of that function. Possibly some weirdness with how C::B is passing the breakpoints to gdb?
UPDATE:
The project I am working on is Exim, which links the code into the build directory (due to some bug with gcc 2.92.x and extern's IIRC). If I open the file from that location in C::B and set a breakpoint it works as expected. I suspect that C::B is possibly passing incorrect references to gdb?
Any ideas?
It would seem that in this situation I need to specify the source path for the source file in question, even though it is within the root source path.
Originally I had my GDB source path set to:
/home/graeme/exim/src
The code in question lives in src/lookups, so adding that path too fixes the problem
/home/graeme/exim/src
/home/graeme/exim/src/lookups
I believe this situation has arisen as the code I am building is initially compiled into a static library, this library is then linked into the main program itself. As such symbols reference the source for the library source files located at the point the library was compiled. So in this case there are multiple packages being built, and I needed to reference each of them in the source paths.
I thinking about some global hook, but googling for "file create hook" gave me nothing.
I doing folder explorer in my prog... and I would like to add / remove files from visual representation in my prog as soon as they got added / deleted / appeared (for network folders), instead of running loop to scan the folder all the time.
Is that possible? I hope for some WinAPI solution.
You can use ReadDirectoryChangesW which notifies you of changes in a specific directory.
Also you can use SHChangeNotifyRegister, which is a shell feature and also works for "shell" forlders..
I suggest to read the following article: Understanding ReadDirectoryChangesW - Part 1
I made some changes in a WPF xBap application and it compiles well but the new changes is not applied and when I put a break-point on the changed lines, the IDE ignores the break-point and shoes the following hint message: "The breakpoint will not currently be hit, No executable code associated with this line."
I tried the following:
Cleaned and Rebuilt the Solution
Cleaned the cache
Restart the machine
and no hope.
Any idea or suggestion will be appreciated.
Note: The application works well with the new changes in the published version but it does not through the IDE.
"No executable code associated with this line"
try to add a debug line Console.WriteLine() and add a break point at that line.
I found the problem, it's because a wrong path in the file projectName.csproj.user.
I opened the file using the notepad and edited it manually.
I have a WPF project which compiles just fine. However, when I enable code contracts, I get a lot of errors like the following:
file 'C:\MyProject\obj\Debug\MyFile.g.i.cs' could not be found
Is there workaround?
Just FYI... This bug has been fixed in the latest version of Code Contracts (v1.2.21023.14, released Oct. 22nd).
Can you be a bit more specific about your repro steps? The significance of the files ending in .g.i.cs is they are files generated specifically to enable intellisense in running projects. They are not truly part of the build process and likely should not be consumed by code contracts. I'm not a code contracts expert by any means though so I could be wrong on this point.
I posted a repro and workaround to this problem on the Code Contracts forum. Here's the URL:
http://social.msdn.microsoft.com/Forums/en-US/codecontracts/thread/4f2af748-1db1-4175-abf0-fbcc82f177ee
The short answer is that the error occurs whenever you have multiple projects that reference each other in a Solution, and one of the child projects is a WPF control library. To get around the problem, you can either disable contract verification for the parent project(s) (the ones that reference the other projects), or you can add a post-build event to the offending child project(s) to create the *.g.i.cs files that the Code Contracts rewriter is looking for.
For example, create a blank text file in the root directory of your child project and name it "Blank.txt". Then add the following command as a post-build event in that project:
copy "$(ProjectDir)Blank.txt" "$(ProjectDir)obj\$(Configuration)\GeneratedInternalTypeHelper.g.i.cs"
Copy this line as many times as needed, one for each missing file.
I'm trying to add a .settings file in a windows form application by adding a (whatever) file in the project and have it named smthng.settings. Right after it is created, it crashes (if I look into the project's directory the file is there, but it's not "in" the project). Am I doing it wrong or could it be that the problem lies elsewhere?
Edit: It seems that it's the settings designer that crashes.
Partially Solved:If I add a (whatever).config file, then rename it to .settings and change it's file type to C/C++ Code (don't ask how I figured this out..) then I can add to it settings, but if I do add something that has any connection to the form then automatically a (whatever).config with thew same name spawns (which is identical to the (whatever).setting even if change one of them) and at the stdafx.cpp a #include '(whatever).h' appears, which is a problem, because there is not such a header. (if I erase it or just create a blank (whatever).h it doesn't work. Apparently I have to somehow connect all the data in the (w/e).settings to (w/e).h as well or maybe something else) Anyone had this problem before? Anyone has any ideas?
If it crashes, then regarding of what else you may be doing wrong, it's a bug - software shouldn't crash on invalid user input. That said, the causes could be anything from bug in VS itself, to bug in some third-party extension you're using, to system problems.
Make sure you have all the latest OS updates and service packs for VS2005. If it still repros then, report it as a bug to Microsoft Connect, and people responsible for this product area will take it from there.