Alternate to Conditional Compile Statements?

[Robert W.]

I have a library that I'd like to have both a WinForms app and a CF app
utilize. Generally the code is very compatible but sometimes there are some
differences.

At first I thought I could use conditional statements like #if (POCKETPC),
#else, and #endif to differentiate different code constructs but then I
learned that these only take effect at compile time.

So I'm wondering if there's another way for code to differentiate at run
time and still execute properly.

Any ideas?


--
Robert W.
Vancouver, BC

https://www.mwtech.com

[Chris R. Timmons]

Re: Alternate to Conditional Compile Statements?

=?Utf-8?B?Um9iZXJ0IFc u?= <RobertW@discus sions.microsoft .com> wrote
in news:6A62DDBF-DAF7-4C06-A3EF-8C825F823E44@mi crosoft.com:
[color=blue]
> I have a library that I'd like to have both a WinForms app and a
> CF app utilize. Generally the code is very compatible but
> sometimes there are some differences.
>
> At first I thought I could use conditional statements like #if
> (POCKETPC), #else, and #endif to differentiate different code
> constructs but then I learned that these only take effect at
> compile time.
>
> So I'm wondering if there's another way for code to
> differentiate at run time and still execute properly.
>
> Any ideas?[/color]

Use System.Environm ent.OSVersion to determine what OS your code is
running on.

--
Hope this helps.

Chris.
-------------
C.R. Timmons Consulting, Inc.

http://www.crtimmonsinc.com/

[sdbillsfan@gmail.com]

Re: Alternate to Conditional Compile Statements?

I really don't think it would be a good idea to do it this way both in
terms of code readability and performance. Keep the common
functionality in the current library but separate out the CF and
Windows specific classes into their own libraries.

[Robert W.]

Re: Alternate to Conditional Compile Statements?

Chris, sure that tells the code which environment it's running in but
unfortunately calling a method that has any illegal code (for its
environment) will crash the method even before it starts.

SDBillsFan, I think what you're saying is my only choice. What has me
really bummed is that I had some specialized code for dealing with datasets.
It worked PERFECTLY with my WinForms app, which I built first. But now I'm
trying to get it working with my Pocket PC app and it ain't working. The
reason, apparently, is because the "DataSet" object in the WinForms
environment is not the same as the "DataSet" object in the CF environment.
So even a statement as simple as the following crashes, if executed in the
DLL in the CF environment:

DataSet dataSet = new DataSet();

But if I move the same code to my main CF app then it works fine.
Frustrating!

--
Robert W.
Vancouver, BC

https://www.mwtech.com

"sdbillsfan@gma il.com" wrote:
[color=blue]
> I really don't think it would be a good idea to do it this way both in
> terms of code readability and performance. Keep the common
> functionality in the current library but separate out the CF and
> Windows specific classes into their own libraries.
>
>[/color]