OpenNETCF ButtonEx problems

[carmen]

I've installed the 1.2 version of OpenNETCF and I cann't run my project
because of the obsolete properties. How could I remove these properties? If
I clear the code lines they appear always I press the F5 key to compile.
Please help!!
Carmen

 

[Dan Bass]

I know... i reverted back to 1.1 where the cool features still existed.

For some reason the guys feel this compelling need for OpenNetCF to exists
only to cover the space between the .Net CF and .Net frameworks.

If you go through each button that it is complaining about and in the code
remove the obselete properties this should do it. Try pressing F7 as this is
just compile (where as F5 is compile and run).

 

[Tim Wilson]

Keep in mind that there are different audiences here.

One group of devs might only look at WindowsCE/PPC/Smartphone development
and don't really have a need for desktop development. To these people
writing code that only runs on, let's say a PPC, is all that matters. So is
writing OOP code that can be easily reused and maintained between a desktop
project and device project important? What about being able to "refactor"
your code at some point down the road so that you are just compiled against
the CF? There is a very good possibility that MS will follow the desktop
naming convention and so we should as well. The SDF is amazing but some
people might only be using this to bridge the gap between CF 1.0 and CF 2.0.
Once the features that they are using have been implemented in the CF they
would like to be able to migrate off of the SDF. Yet others might not care
about this either. The SDF will stay in their applications even though the
functionality is there in the CF itself. Another group of devs may like the
possibility of code portability/compatibility between the desktop and
devices. This group would like to be able to share code between different
projects (both desktop and device) as much as possible.

I think the most ideal way is have the controls that exist in the
OpenNETCF.Windows.Forms namespace conform to either the control/component in
the CF, if they are replacement controls, or to the desktop framework if
they are control properties that do not exist in the CF or entire controls
themselves. Then developers that have a need for compatibility and long term
"refactorability" can stick with this namespace. While another namespace,
let's say as an example OpenNETCF.Windows.Forms.Extended, can be used to
extend controls in the OpenNETCF.Windows.Forms namespace with all these
beautiful and pretty properties to allow people to show different images
based on button state and anything else that might come up.

I guess the idea is to cater to as many different audiences as possible.
It's not an easy thing but friendly suggestions are always welcome...

 

[csharprox]

Those are just warnings; you should still be able to compile. Do you have
un-related errors?

C