I created a data model in Xcode with about 9 entities, all of which are connected via relationships to a single 'core' entity.
Once I set this data model up graphically using the "Graph Editor Style" for the xcdatamodelId, I generated the class files by going to Editor -> Create NSManagedObject Subclass. I did this twice to establish all classes so there were no properties of type "NSManagedObject".
However without touching any of the generated files, I am getting 4 errors for one of my class entities (Style), all of which are:
Semantic Issue - Redefinition of 'Style' as a different kind of symbol.
Considering these files are generated, I'm more than confused as to what I need to do to fix these. The relationships between entities are straightforward, and there is nothing special about the 'Style' entity which differentiates it from the rest.
Is this possible due to the forward declarations in the various files? I'm stumped as how to rectify this - and I'm a beginner with iPhone development so I'm not quite sure how to approach this. Help is greatly appreciated!
You cannot create a class named Style
it is already defined on MacTypes.h
You should always prefix your classes with your own namespace i.e. Style should be DWStyle
Related
I need to implement a custom ResultHandler but I am confused about how to actually integrate my custom class into the software package.
I have read this: http://elki.dbs.ifi.lmu.de/wiki/HowTo/InvokingELKIFromJava but my question is how are you meant to implement a custom result handler such that it shows up in the GUI?
The only way I can think of doing it is by extracting the elki.jar package and manually inserting my custom class into the source code, and then re-jarring the package. However I am fairly sure this is not the way it is meant to be done.
Also, in my resulthandler I need to output all the rows to a single text file with the cluster that each row belongs to displayed. How tips on how I can achieve this?
There are two questions in here.
in order to make your class instantiable by the UIs (both MiniGUI and command line), the classes must implement our Parameterization API. There are essentially two choices to make your class instantiable:
Add a public constructor without parameters (the UI won't know how to set your parameters!)
Add an inner static class Parameterizer that handles parameterization
in order to add your class to autocompletion (dropdown menu), the classes must be discovered by the MiniGUI/CLI/other UIs. ELKI uses two methods of discovery:
for .jar files, it reads the META-INF/elki/interfacename service files. This is a classic service-loader approach; except that we also allow ordering instances.
for directories only, ELKI will also scan for all .class files, and inspect them. This is mostly meant for development time, to avoid having to update the service files all the time. For performance reasons, we do not inspect the contents of .jar files; these are expected to use service files.
You do not need your class to be in the dropdown menu - you can always type the full class name. If this does not work, adding the name to the service file will not help either, but ELKI can either not find the class at all, or cannot instantiate it.
There is also a tutorial on implementing a custom result handler, but it does not discuss how to add it to the menu. In "development mode" - when having a folder with .class files - it will show up automatically.
Just started using VS 2012 and I generated an EF Model from the database. All worked fine, although in my previous experience I had to put a using in my code.
I tried to set up a .cs file with partial classes to provide custom business logic behaviors to the generated classes and Intellisense does not recognize ar prompt with the generated classes.
I did as others have stated and brought up the properties panel of the Edmx model and fount the namespace. However, when I try to put it in a using statement, Intellisense does not recognize it.
Am I missing something here? EF can get very confusing and frustrating if one goes more than an inch or so below its generated surface.
Turns out that EF5 generates a model such that you do not need to have a "using namespace;" or a "namespace xxx"{} in the code file.
Just a simple xxx.cs file and each partial class definition you want to make:
public partial class MyClass
{
}
I have about a half dozen tables coming from a legacy web server. These tables all have a "type" column. I need to keep these column names in sync at the app level.
Using mogenerator, the base class it creates dutifully generates a setPrimitiveType attribute. Well Apple doesn't like this method and rejected our app.
Is it possible to change mogenerator to not create certain methods of the model's attributes?
Yes, it is possible to fine-tune what mogenerator creates. This is done by updating the entries in the templates for the machine files. For example, the following lines can be commented out from the machine.h template file.
- (void)setPrimitive<$Attribute.name.initialCapitalString$>:(<$Attribute.objectAttributeType$>)value;
- (void)setPrimitive<$Attribute.name.initialCapitalString$>Value:(<$Attribute.scalarAttributeType$>)value_;
The former is the regular accessor. The latter is the scalar accessor and it could even be renamed if desired.
However, do notice that the Core Data framework and not mogenerator are generating the basic accessors as pointed out by the Apple Docs Core Data Programming Guide:
For example, given an entity with an attribute firstName, Core Data automatically generates firstName, setFirstName:, primitiveFirstName, and setPrimitiveFirstName:. Core Data does this even for entities represented by NSManagedObject. To suppress compiler warnings when you invoke these methods, you should use the Objective-C 2.0 declared properties feature, as described in “Declaration.”
I had the same problem with 'type' keyword.
My solution was manually creating and implementing methods like
- (NSNumber *)primitiveType;
- (void)setPrimitiveType:(NSNumber *)value_;
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?
I'm trying to run codeanalysis on an assembly that contains an entity model (edmx file). In project properties I have checked the "Suppress results from generated code" option, but I am still getting a lot of CA errors pertaining to the auto-generated EF code.
Has anyone experienced this? And is there a work-around?
Just put the attribute on your class definition.
But how to do it, since your file can get overridden any time. Use a separate file, since all generated classes are partial classes. Open a separate file, and write something like:
[GeneratedCode("EntityModelCodeGenerator", "4.0.0.0")]
public partial class YourEntitiesContextName : ObjectContext
{
}
This will skip code analysis on your particular generated class. StyleCop for instance is more smart and doesn't touch files that have .designer/.generated part in their name or regions that have generated word in their name.
Well, "Suppress results from generated code" really means "Don't look at types with GeneratedCodeAttribute". EF's code generator hasn't added this, historically (though I've suggested it to the team). But you can add it if you use custom T4.