Annotations Issues

Hey,

I've run this by our compiler engineer here and she is taking a look. I've created a ticket.

Thanks,
-Coleman

Hey,

I've run this by our compiler engineer here and she is taking a look. I've created a ticket.

Thanks,
-Coleman

Thanks. I'd also like to put in a plug for the ability to do conditional compilations. Exclusion annotations help, but it'd be nice if you could basically do conditional compiles on blocks of code based at compile time. Particularly with the resources being so limited on some of these devices and inefficiency of data structures, it would be great to make it easier to add more advanced functionality when devices support it. Personally I'd vote for something along the lines of c# such as

#define isEpix //in the code file or in a resource file as <build> <define isEpix="true"/><build>

#if isEpix
any code
#else
different code
#endif

In this case, the code could be anything. It's just text until it gets compiled. And then the compiler just ignores anything that isn't defined.

Then being able to define "isEpix" either in an resource file as well as in the code itself, again like in c#. Being able to define it in the code file allows for simple debugging code to be turned on/off

Lastly, being able to do simple boolean logic such as

#if isEpix || isVAHR
#else if ...
#endif

The great thing about all of this is it happens at compile time rather than run time. I'm trying to figure out right now how to have 3 versions of my TrackerSensor implementation work with 3 levels of functionality depending on if it is an App (full feature), data field (minimal implementation) or widget (middle implementation). The two lower levels are just subsets of the full version but no easy way to achieve this right now. So when I fix an issue in one, I need to change all 3 code files.

I came into CIQ as a long time "c" guy and was also looking for what you describe - the good old "#ifdef - #else - #endif"!

I have one app that supports a number of devices and has a number of screens - and I don't use layouts. The whole display part had turned into spaghetti code over time, and I'm not sure annotations would have made it easier to maintain. What I ended up doing with exclude, is not to use annotations, but use different .mc files, so I could have something like vahr.mc and semiround.mc, and exclude the .mc's that aren't for the specific device. It's nice in that if I change something for the vahr, there's no impact on the other devices even possible, and nothing in the main .mc that's not used on all the devices, and this is all set up at compile time.

In your case, where you have different projects (the widget and two app), maybe something similar, but have the device specific code in a shared (linked) file, so you'd only have one .mc for the Epix, and when you change that, it's used by all the projects?

...

In your case, where you have different projects (the widget and two app), maybe something similar, but have the device specific code in a shared (linked) file, so you'd only have one .mc for the Epix, and when you change that, it's used by all the projects?

I like the shared .mc option. I am still working on the merge but was planning on just copying the file to other two projects. But was trying to avoid needing to make the current changes I do now each time I do the copy. I haven't tried but I assume I can just drag the epix version over to the other projects and tell it to link the file rather than copy. Good suggestion.

Yes, I have the exact same issue with drawing where I have "spaghetti code" to deal with the various flavors. I too avoid layouts. Data field drawing gets really interesting where each device has several different shape areas for your drawing.

A bit more about how I do shared .mc's - In my workspace, I'd have three directories, for example - project1, project2, and shared. The .mc is only in "shared". Then in the source directories for the two projects, I have a link to the common .mc. I started with windows symbolic links, but now use the links in eclipse itself ("new>file" allows you to set up links, and you can also link an entire directory with "new>folder"). If I'm working on project1, change the shared .mc, when I move to project 2, it's already got the change, so no way to get out of sync with different .mc's

Any questions, PM me. Coleman might not want this in the Bug Report Forum! :o