All of a sudden I'm getting over a hundred warning messages of that sort out of XCode build (that used to build without any warnings), but, curiously, when you look at the connections in Interface Builder there's no problem, buttons that are reported to lack connections work fine, and in every other way the application seems normal.
It's happening with several different view controllers and XIBs, some of which have some some stuff in common, but one which is entirely different from the others, with no includes in common, no common interfaces (other than Apple's), etc.
I tried clean, and I tried deleting the entire build directory, to no avail. Looked for files that may have gotten dragged out of place in the XCode file listing, but nothing obvious.
Any ideas?
Solved: Apparently someone in our group is using a later version of IB and checked in the XIBs. They're semi-incompatible with 3.2 until they're edited once, then the warnings go away.
Related
A little configuration information to start:
Xcode 13
Qt 5.15.5
iOS 14.7.1 (18G82) (I'm running on a device, not a
simulator)
Host MacOS Big Sur 11.6
I'm debugging a large Qt app, all written in C++, except for the necessary few files to make it work in iOS (so it's really an Objective-C++ app with an enormous amount of native C++ linked to it, everything of Qt it needs). I have a break point within the LoadApplication method - Qt has been built from source for development (that is, in debug configuration with symbols). There are a number of native Qt QUrl objects whose values I'd like to inspect. I have successfully installed lldbbridge.py, but I think the problem may be unrelated to that, because I saw it when I was using other tricks to see the data without the bridge. There is a method called toString on the QUrl class that produces a text representation of the URL (and another called toDisplayString that may be more human readable). These methods produce (of course) QString objects. So here are the failure modes:
First the bridge should be helping me to inspect the QUrl and all I see are the raw object descriptions that hide all the private interfaces. It isn't.
before I installed the lldbbridge.py script, I was able to view some of these objects (local variables, but not parameters), using code like expr url.toString().toStdString().c_str(). It still might work on local variables, but I would really like to be able to inspect parameters as well.
the error feedback I get is
error: <lldb wrapper prefix>:21198:9: module 'std' not found
#import std;
~~~~~~~^~~
this is a pretty legit error, because I have scoured my system and the internet for evidence of this std.framework whose existence is implied, and cannot find it, though its name suggests that it would be an assist to Objective-C or Swift to deal with std::string and the like. Possibly it was a thing in Xcode 12 that has been dropped in Xcode 13, but if so, it has no footprint on the web that I can find. Still, presumably Qt 5.15.5's lldbbridge.py was compiled and run and against it at some point in the recent past.
this isn't the only trick that doesn't work when inspecting a QString, with or without the bridge. I also tried expr (const wchar_t*)url.toString().toUtf16() and expr (const char*)url.toString().toUtf8() and so forth. The same error feedback results, complaining about the mysterious "std" framework or module.
and don't get too hung up on QUrl objects, because I get the same result with other QStrings.
one more symptom: if I do an expr #import std; in the lldb command line, it appears to work. That is, it gives no error feedback and appears to complete. This just makes the world weirder, because if exists, it must be hiding somewhere inside Xcode's contents, but I've done file searches in there, and see no evidence of such a thing. And if it does exist, why is the lldb wrapper prefix giving me grief? Could the wrapper be underspecified in terms of framework search paths, but the lldb command line not?
So as if it's not too obvious, here are my questions (besides WTF???):
Am I the first to see this? I've seen some forum talk about string inspection no longer working for others in Xcode 13 lldb, but the specific failure mode is different. Anyone else see this?
Does anyone have any idea about this mysterious "std" framework or module? Could its functionality have been sucked up into some other module or framework for Xcode 13?
Any ideas about work-arounds that I haven't thought of? I'm not a complete lldb novice, but I'm not an expert either.
I'd like to turn up the log levels look at those for clues, but I've never used that feature before, and I don't really even know where to FIND the logs.
I notice that the feedback suggests that there are at least 21198 lines in this "wrapper" BEFORE we get to the failing import statement. Seems a little excessive to wrap a request to view the contents of a string. Perhaps the whole wrapper is corrupted in some way. Any thoughts on how to test that hypothesis? How about a way to inspect the contents of the wrapper prefix itself?
Could the #import std; be a red herring and just co-lateral damage in some other unrelated failure mode? It's tempting to imagine it's some kind of std library support thing, but I don't want to assume too much at this point.
one more things about "std", whatever it is - lldb is super dynamic. It's always compiling inline code on-the-fly to support its functionality. That's the whole llvm magic. Is it possible it exists only as some inline text within lldb's source? And again, if so, why is it only selectively available?
Well, that's my nightmare. Unless my setup is horribly corrupted in some way and it's my unique curse, I'm sure this problem will show up for others, so cogent answers will make you a hero. Any pointers are appreciated. Thanks.
Before anything, I will first say that I've been looking everywhere for a solution to this problem for an hour now. There are many identical problems out there but none of the solutions help me.
I'm trying to debug a small project. When I started working on the project, I could place break points wherever I wanted and I would hit them. But for some reason, now when I place breakpoints outside of the main program (in a class definition, for example), the breakpoints hollow out while the code is running and I get a message saying the source code is different from the original version.
This led me to believe it was running a previous build, so I made an obvious change by having the code output some random letters "dajfhdjhfds";
I hit F7 as usual. Got a message saying Build: 1 succeeded. Hit F5, the program runs but does not display the random letters.
I clean my solution, then build and the changes show. I 'rebuild' the solution, and the changes show. The breakpoints also work.
But then if I make further changes, the breakpoints stop working and the changes don't appear in the program. Visual Studio is always running old code. I don't want to have to clean my solution every time I want to debug new code.
I've reset my settings, I checked off "build" in the configuration manager, I even started a whole new project and copied my code into new files. Same issue.
The problem resided in the fact that I copied the code from the original project into a brand new project saved elsewhere. When I tried to build the project in the new location it would always build it in the old location (Strange since I copied code directly into brand new files).
When I tried to run the files it would look for the built code in the new location. Therefore it would always get out of date code.
Problem can be fixed by putting the new code back in the old location!
Thanks everyone
I had this problem occur also, using WinForms. I was adding message boxes to test code and nothing was happening, only the pre-existing message boxes worked. I'm not sure 'exactly' how I fixed it, but after clicking "Build Solution", "Rebuild Solution", "Clean Solution" and "Build (program name)" all under the 'Build' menu the problem went away. Unlike the previous problems I had not copied+pasted any code between solutions.
I've started running into an identical problem and I think it all started when I re-created the project under a new name.
That is, I had to copy everything.
Problem is I don't know what DIDN'T get fully copied and is now responsible for requiring a rebuild to get my code changes. Checked the solution and project files in a text editor and no signs of the old folder structure.
I am working on a rather large project, and I am having strange problems with the IDE in terms of error checking and somewhat with IntelliSense.
Usually if I were to type something boneheaded, like "int a = "aa";", it would underline "aa" in red. However I am seeing VS do this to random parts of my code when I make insignificant changes.
For example:
/*
Some comment here, just going to stretch it out for my example..
*/
int proto1();
int proto2();
If I make changes to other parts of the project, sometimes random functions will get underlined, and even part of a comment. Like just 30 minutes ago it underlined the equivalent of half of that comment beginning in the middle of the word "comment", also it underlined all of int proto1(); and part of int proto2();
I would post screenshots but I am bound by contract not to disclose any work, and I can't easily replicate it in smaller projects.
I don't understand why it does this. When I compile the project, any fake errors and underlining it did goes away and it compiles fine. The point though, is there are no errors. It's making up random errors and underlining random lines/words/half words. I would also like to note that there seems to be a large delay in loading new intellisense information, almost by 2-3 minutes or longer.
I'll try and reproduce it in an unrelated project and post here if I can. However, any help would be appreciated.
Thanks!
*Edit: Forgot to note that hitting the space key several times will on occasion correct the errors however this isn't reliable and does not always work.
Intellisense sometimes can really get stuck with complicated code. I guess until VS2012 release comes out, there's nothing we can do.
There's however one trick that I'm using if this happens - switch your build configuration Debug -> Release and then back again. You don't have to wait, you can just click two times on this drop-down box. It should refresh IS cache and make red error underlines dissappear.
Intellisense is often off, but make sure you have latest updates installed.
I just installed sp1 yesterday and lot of Intellisense issues went way.
I see this is a stale question but some may find this helpful.
I just had this same issue. I tried many of the solutions outlined here and elsewhere. I finally tried running Visual Studio as another user (Shift Right Click Run As Different User) and the issue did not present. I then logged into my computer as another user and deleted the profile of the user I was having the issue with.
If your profile is important to you or there is information within it that is important I highly recommend backing up relevant information first. If you don't understand what information you profile contains make sure you do prior to deleting it.
1) Log in as different user (with admin privileges) than you want to delete
2) Open Properties for Computer
3) Advanced system settings (on the left side)
4) Settings for User Profiles (in the middle)
5) Select the profile you want to delete and click the delete button
6) Reboot
Credit to:
https://superuser.com/questions/63017/how-do-i-delete-a-user-profile-on-a-windows-7-machine-that-is-part-of-a-domain
I had the same issue, and in my case it was mostly related to library functions and types defined in libraries. This one fixed it for me:
Open command line parameters. You can use following to reach there:
Project > ProjectName Properties > Configuration Properties > Linker > Command Line
In the Additional Options box at the bottom add
/I "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include"
You will of course need the correct path where Visual Studio is installed.
Bingo! I hope it works for you too. :)
We're using MFC data exchange to validate some data and we're having some problems. We're using the DDV_MinMaxFloat call to ensure that edit boxes in various parts of the application contain floating point numbers within a specified range. When using this validation if a value is entered out of range a dialog is automatically displayed to the user indicating that the value must lie within the range specified. This has been working correctly whilst running the application in debug however when building a release we are getting problems. The validation is still performed in release mode however the message box displayed to the user is blank.
I've tried the usual forcing a rebuild, deleting old resource files and deleting precompiled header files but this continues to happen in release mode. Has anyone come across this before? Are there any obvious things to look for?
I should also add that this application is over 10 years old, so obviously has been working correctly before. Somehow something has gone wrong in the last few weeks to cause this.
Those messages will come from MFC's resource strings. There might be some conflict with your own resources. Check to make sure your resources adhere to Microsoft's guidelines TN020: ID Naming and Numbering Conventions.
Pay particular attention to this bit:
MFC's internal framework implementations reserve two ranges: 0x7000
through 0x7FFF and 0xE000 through 0xEFFF.
Somehow something has gone wrong in the last few weeks to cause this.
Since your application worked fine a few weeks ago, it should be easy: check out the last working version from your revision control system and compare it with the current version. Or try to narrow it down to the first revision which does not work any more.
Check with Spy++ if there are controls on the message box that is displayed and if the text on them is blank, or if there's no controls on them at all. If the text is empty, you'll have to check the resources or the way the messagebox is called/created. Otherwise it may be something like resource being set incorrectly and the message assuming it can read its resource strings from ::AfxGetResourceHandle(). Note that this is a very easy error to make - it's a global handle that can be changed everywhere (including in dll's that you have no control over) so changes in remote parts of the code that at first sight seem unrelated may trigger it.
I have a solution with 21 C++ projects and 1 VB.NET project.
The IDE responds very slowly when I simply move the carret in a file or try to open the menu. The process seems to take 50% of CPU for each movement.
It only happens with this solution and only on my machine.
The solution has total of 2380 source and header files, of which 1280 are header files.
I tried to remove all connection to the source control (Perforce) but it didn't help.
Also, I have Visual Assist installed but even after removing it (uninstall), the same behavior continued.
Any idea?
Deactivate intellisense.
Link
Intellisense parses the whole project and slows down the IDE drastically. If you use Visual Assist then you won't really need it. Visual Assist is less resource hungry and scans in the background, intellisense steals too many resources during its parsing.
Could this apply in your case?
http://coolthingoftheday.blogspot.com/2008/03/visual-basic-2008-hotfix-to-fix-slow.html
Note that disabling Intellisense may also break stuff like the Class Wizard (at least I'm pretty sure it does in VS2005). As already suggested it's a good idea to get rid of all the temporary files like .ncb regularly, because they can get huge and will slow down the IDE.
Also, if you're using Visual Assist, try rebuilding the database, disabling it or installing a different version.
I have a few solutions with over 100 projects, so I know exactly how you feel. Solutions containing some managed projects are especially bad. Disabling Intellisense helps a lot. I've never seen such problems from Visual Assist (or other similar refactoring tools), and that fills in a lot of the missing functionality from losing Intellisense.
I've also encountered some projects that had code that would cause the Intellisense thread to endlessly loop and never finish parsing the code. Most of those times we were never able to pin down the exact bit of code that caused the problem. Certain heavy use of templates and nested macros were often high on the suspicion list.
The only good way to be sure that Intellisense is disabled is to create a directory with the same name as the ncb file. Go to your solution directory, delete the ncb, and create a directory named your_solution_name.ncb. Because it can't recreate the ncb file, you'll get an error box to click through every time you open the solution, but that's a small price to pay.
Simply deleting the ncb will mean that VS will just create it again. The methods that I've seen from inside the VS options will turn off some of the features but will not prevent it from trying to parse all your code.