LESS Mixins aren't available in other imported LESS files - import

I have this code:
#import "vars.less";
// Desktop/Laptop Section
#import "mixins-d-1.less";
#import "positioning.less";
#import "containers-d-1.less";
Inside containers-d-1.less I reference a mixin from mixins-d-1.less. However, I get an error saying that it's undefined.
I'm able to pull my variables out of vars.less, why can't I pull my mixins out of mixins-d-1.less?

The problem wasn't the importing at all, really.
I made a mistake in how I was using media queries.
Both files had the same media query since they were both for the desktop CSS (hence the "d"). However, the second one, in containers-d-1.less was OVERWRITING the first one and blowing away all my mixins! I clearly need to wrap the import block in a single media query for that section instead of redeclaring it inside each less file.

Related

Duplicate Interface Definition When Implementing FBConnect

I am trying to add FBConnect to my application which includes the SBJson framework. However, when I try to compile the project I get these two errors:
Duplicate interface definition for class 'SBJsonWriter'
Duplicate interface definition for class 'SBJsonParser'
What can I do to fix this error? Thanks for any help.
Delete
#import FacebookSDK/FacebookSDK.h
In your project
I start using FacebookSDK, but then I was disappointed with it's current state and tried to use the old "FBConnect", that's how I have got the error
There are two possibilities:
you have two interfaces with the same name. Use Xcode's find in project menu option to find instances of SBJsonWriter. Then rename one of the interfaces
somehow you have managed to import the .h file twice. Check to make sure you always use #import and not #include.
A bit more info on #import/#include:
include blindly includes the file at the location of the #include statement. This means that if you #include a file twice in your .m you will get two copies of the file. Almost all traditional C #include files have something like the following bracketing all the content:
// some_file.h
#if !defined SOME_FILE_H
#define SOME_FILE_H
// entire content of #include file
#endif
he above is sometimes referrwed to as an include guard macro.
In Objective-C, if you #import a file, a check is performed by the compiler to make sure it has not already been imported. Consequently the guards are usually omitted. So if you #include a file that was supposed to be #imported, neither check will be done and you will sometimes get duplicate definitions.

Suppress warning: Meta method xx in category from xx conflicts with same method from another category

How can I suppress this compiler warning:
Meta method 'prefix' in category from '...soap+prefix.o' conflicts with same method from another category ?
here is the category soap+Prefix.h:
#interface Soap (Prefix)
+(NSString*)prefix;
#end
and soap+prefix.m:
#import "Soap.h"
#import "Soap+Prefix.h"
#implementation Soap (Prefix)
+(NSString*)prefix { return #"EInspector"; }
#end
and these two files by the way are automatically generated with SudZc wrapper for web services.
p.s. this warning is issued ONLY in XCode 4.4
thank you so much in advance.
This happened to me when I have accidentally imported an implementation file of a category (.m) instead a header file (.h).
Somewhere else in your project, +[Soap prefix] is being declared in a category. Try searching your project for other declarations of +prefix.
Another possibility is that during a large refactoring or complex merge of your project.pbxproj file, the project ended up with two references or copies of the same file, and both are being compiled. I've seen it happen, and these sorts of warnings or errors are usually what happens. Try searching in the Finder for other files with the same name to see if you have a duplicate file somewhere.
In my case the issue was due to a wrong merge of project.pbxproj (so similar to Nick Forge's case), which caused too many references to the same file (however the file was physically only once on disk). When I removed redundant references the warning stopped appearing.
You should reference a great answer by someone who also posted something similar:
Is there a way to suppress warnings in Xcode?
In my opinion the 2nd (highest voted) option is the best!

Parsing multiple XML web file iphone

Let's say i have a xml file with a tag named which contains the number of fields i want to show in my tableView and in another xml file i have the information to be displayed in that tableView.
The question is : Should i create 2 different file in my project (xmlparse1.h and .m + xmlparse2.h and .m) or should i just put all my code in 1 (xmlparse.h + .m) and differenciate which file i am parsing at the moment with a bool or something like that in the code?
I am developing an iphone app on Xcode 4.3 mac os x 10.7.4 if this might change
EDIT: 1st file :
<MenuPrin>
<humidite>82,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</humidite>
<tempmoy>
189,124,700,700,700,700,700,700,700,700,700,700,700,700,700,700,700,700,700,700
</tempmoy>
</MenuPrin>
2nd File :
<Instal>
<nbrField>2</nbrField>
</Instal>
So it looks like this. So, since nbrField is 2 I would take the 2 first value from tempMoy and humidite and show them in a tableView.
END OF EDIT
If how you're parsing is similar in both instances, to add two sets of files that do effectively the same thing would be extremely inefficient and considered bad practice. It makes a lot more sense to create a parser that can handle the two different files than to write two parsers that can only handle a specific file each.
To more specifically answer your question, I would determine which file you are parsing and behave accordingly, whether you do this with a bool or something else is up to you.
EDIT: Here is the idea that just popped into my head, so if for whatever reason this wont work for you(Like I said its been a while), or someone has a better idea, I'm all ears. You could still have a set of files(.h and .m) that contain the definition of your parser. Your parser could contain within it a two variables of type Object1 and Object2 which are built in such a way that they resemble the data structure that you need to store what you parse once for your first type of file, and a different definition for your second type of file. This way when parsing once you determine which file it is you are reading, it just changes which of these two objects you write into. There are also plenty of variations for how you could set this up, and I can also think of a few cases for what you might be trying to do where this might not work, but there is the idea regardless.
If you think that the two sets of files approach is better for the application you are trying to write and makes more sense to you, given what has been discussed in the comments, it isn't necessarily a bad idea.
In case if u want to create two table view in one view u need to create a single .h & .m file...If u want to create individual table view u need to create two .h & .m...
Try TBXML parser...that is the easiest way and less memory usage for xmlparsing...

what approach for adding custom methods to Core Data managed objects in separate files?

what approach for adding custom methods to Core Data managed objects in separate files? In particular the requirements would be I guess:
don't want to touch the XCode4 generated classes (i.e. so can regenerator them anytime and not have to redo changes within them)
can effectively add methods to the generated classes (assumption is the class names don't change)
Note - I'm aware of mogenerator but I'm not happy with it entirely at the moment noting https://github.com/rentzsch/mogenerator/issues/55
Would the simple and best answer be just Objective-C: Categories?
Fixing mogenerator would be the best answer :-).
mogenerator uses subclasses, so you could always do that, but categories would work as well.
I just tried... What do you think about a simple #include "included_dataStuff" and putting all your extra code into the "included_dataStuff" file.
There are two possibilities:
create a new ClassFile, delete the include "header.h", (delete the header.h), put the extra code there. It compiles but brings the two warnings: (which are understandable)
[WARN]warning: no rule to process file '$(PROJECT_DIR)/Classes/../included_dataStuff' of type text for architecture armv6
[WARN]warning: no rule to process file '$(PROJECT_DIR)/Classes/../included_dataStuff' of type text for architecture armv7
create a new "empty" file and put the extra code there. This does not produce any warnings.
The difference between 1 and 2 is that while the code formatting remains in the first alternatve (having to accept the 2 warnings) in the second all the code format is lost and its treated like normal text (but there is no warning)
I guess I would prefer the first. Of course, the only modification to the generated code file would be the #include statement.
What do you think about that?

Where to #include?

In my past applications I have been #importing into my *.h files where needed. I have not really thought much about this before as I have not had any problems, but today I spotted something that got me to thinking that maybe I should be #import-ing into my .m files and using #class where needed in the headers (.h) Can anyone shine any light on the way its supposed to be done or best practice?
gary
In any source file, import only what you need to make that individual file valid for compilation. #class is also preferable to importing another class's headers, because the less you load the less you compile.
As a rule of thumb it is fine to use #class in your header file and an #import in your .m files. You'll get an error if you do it wrong from the compiler :)
Basically, if you are only making reference to the class you want to use, but not any specifics of the class then #class is all that is required. It tells the compiler "I'm going to be using this class here - you don't need to know much about it, other than that it is valid". (The compiler then knows to reserve a pointer for it).
If you were going to be referencing any properties/methods within the class, the compiler would start complaining (as it wouldn't have enough information about the class) so in those cases it wants you to import the file (#import xxx) in order to provide the class specifics to the compiler.
Hope this helps