How to create a Basic4ppc library

[Cableguy]

Your main concern, if I understand you correctly, would be then to ensure that, your code is DEVICE compatible, causing it to be DeskTop compatible...
If you use some DLL that is "Normal" or "Complete" FrameWork targetted, Then Some or all the properties, controls,events or methods, may not work on the device...

As for myself, and keeping in mynd that the File dialog is somewhat limited, and only shows the files that are 1 level in to the root...(hope I'm making myself crlear, as I don't know all the correct terms), I usually place my files in a Folder, 1 Level down, in the "MyDocs" folder of my SDCard...
In Design Time, any DLL imported to the project is automatically saved to the Apps Folder, so, unless you play around a bit with wich DLL to use in your app, as I often do, all the files needed will be in the Folder...

Hope to be clear enough, and this time to be "to the point"!

[obrienj]

Cableguy,

Let' start over.

An example:

I want to build a B4P library DLL that provides .Net Event processing. Using their C++ names, I will use the .Net equivalent of CreateEvent, SetEvent, ResetEvent, WaitForMultipleObjects, and CloseHandle.

All of those methods exist in both .Net for the PC and .Net CF (both 2.0) and have the same parameters.

My assumption, which could be very wrong, is that I can write one piece of source code that provides the functionality for creating an event, waiting for event to be posted, posting the event, and destroying the event.

In the simpliest case, I would have to compile that source twice, once for the PC and once for the device, in each case creating a DLL with the same name.

So far, is my assumption correct?

If so, how do I manage the source file, the two output files, and the project file?

Or, is the simpliest way to simply treat them as two different projects (one for the PC and one for the device) and manually keep the source the same in both.

Regards,
Jim

[Cableguy]

Originally Posted by obrienj

Cableguy,

Let' start over.

Yes, let's...

An example:

I want to build a B4P library DLL that provides .Net Event processing. Using their C++ names, I will use the .Net equivalent of CreateEvent, SetEvent, ResetEvent, WaitForMultipleObjects, and CloseHandle.

All of those methods exist in both .Net for the PC and .Net CF (both 2.0) and have the same parameters.

My assumption, which could be very wrong, is that I can write one piece of source code that provides the functionality for creating an event, waiting for event to be posted, posting the event, and destroying the event.

In the simpliest case, I would have to compile that source twice, once for the PC and once for the device, in each case creating a DLL with the same name.

So far, is my assumption correct?

Yes, very.
As I sayed before, any DLL targeting the Compact(ed) FrameWork, WILL run on bothe platforms.

If so, how do I manage the source file, the two output files, and the project file?

Or, is the simpliest way to simply treat them as two different projects (one for the PC and one for the device) and manually keep the source the same in both.

The only Problem I forsee, is that Compilation wise, the resulting EXE file ARE diferent...
So, Yes, Two (or more, since B4PPc has added support for Smartphone compilation) diferent EXE would have to be created, trough compilation on the IDE, targeting the especific platform as needed...Still all the other files (i.e. DLL, Txt, etc) would be the same....
In some cases, especially with the legacy and forcedQVGA Mode compiling, some extra files may be created during compilation.

The souce file (.spb) does Not need to be provided with the compiled project...unless of course, you make it available for your own purposes.

[obrienj]

OK, I suppose the best course is just to manually manage the projects with a PC and Device folder structure where separate project files are maintained and possibly a common source folder.

But you said one thing that I don't completely understand.

As I sayed before, any DLL targeting the Compact(ed) FrameWork, WILL run on bothe platforms.

Are you saying the that PC and Device DLL are identical? Aren't the architectures of the CPU's different and thus the instruction set and thus the generated code or am I really missing something?

Or are you saying that by targeting .Net CF they are functionally the same, guaranteed not to use incompatible classes, BUT the actual DLL generate code is different and thus there are two DLLs, one for PC and one for device. The only things they share are use of .Net CF, their name, and source.

I had assumed that I had to have two versions of the DLL just like the B4P.exe files.

If they are different then the manual management will be fine.

Hope you have a nice weekend.

Regards,
Jim

[Cableguy]

Are you saying the that PC and Device DLL are identical? Aren't the architectures of the CPU's different and thus the instruction set and thus the generated code or am I really missing something?

All WIndows Mobile devices (from WM2003 up) are pre-loade with a Compact Framework.
If your DLL as been built to work with the Compact Framework, let say, 2.0, Then, as long as you also have the .Net Framework 2.0 installed in your Desktop, IT will work...
Proof os that is some of the B4PPc packaged Dll's have only one file that works both in the device and the desktop, as the Sprite.DLL, you only have to be sure you have add it in the components, to both the device and the desktop....
Some other DLL's, like CryptoDevice and CryptoDesktop, have two version, specific to their platforms...So they should be added to the correct target in components...
But the same object can be used in any case...
for instance a cryptodevice object called crypt, can also be used with the cryptodesktop, without any problem...Because the compiled file will only be using the correct DLL....and in this particular case, you only need to keep in the folder, the targeted DLL...ie, a device targeted app, developed in the desktop, will have both DLL's added in design time, but in order to run, in the device, it only needs the device version DLL...

I hope I'm beeing clear, but since english is not my mother language, I appologise for any missplelling, or missunderstanding i might have created...

Hope you have a nice weekend.

Regards,
Jim

Thank's, i will try..
Hope your's is twice as good...
Happy codding!

[obrienj]

Cableguy,

Don't worry at all about your English, you do very well. In all the years I traveled internationally with a large computer company, it always embarrassed me to not be able to speak another language but I just don't have that talent. Fortunately during the last years with that company I traveled with a guy who spoke and wrote 11 languages and picked up new ones like I drink sodas.

Anyway, I have been doing some testing and, quite frankly, playing.

Is the following true? (I think you may have already said this but it didn't sink in.)

If I compile my C# DLL targeting NET CF and I compile my B4P program as a device .exe, both will run on both platforms?

OK, if that is true, why? Is C# coupled with Net CF interpreted like Java? If not, I really need an explanation.

Regards,
Jim

[Cableguy]

Originally Posted by obrienj

Cableguy,


Is the following true? (I think you may have already said this but it didn't sink in.)

If I compile my C# DLL targeting NET CF and I compile my B4P program as a device .exe, both will run on both platforms?

NO! The Dll will be useable by both a device compiled or a desktop compiled app, but, a device compiled app will NOT run in the desktop and vice-versa, even if the source file (.spb) is the same.

Is C# coupled with Net CF interpreted like Java? If not, I really need an explanation.

Surelly there is someone with more insight knowleage than me about this issue, but as far as I know, C# is part of the .NET Framework, as well as other # languages like #j...
The main difference is that not All controls, properties, method,etc... have been provided by all those languages, as it was a prerrogative of their own developers/implementers...
the main reason that c# is so far spread in the community, is thet it seems to have the more broad coverage of the .Net Framework, thus giving the more flexible programing eviroment...

[obrienj]

Cableguy,

NO! The Dll will be useable by both a device compiled or a desktop compiled app, but, a device compiled app will NOT run in the desktop and vice-versa, even if the source file (.spb) is the same.

OK, something is strange with what I'm doing.

I compiled the DLL (MyDLL) targeting NET CF. I then compiled the B4P test program specifing Device EXE as the target.

As a reult I have only 1 MYDll.DLL and 1 test_MyDLL.exe.

I copied both to my device using ActiveSync's Explore Pocket PC and successfully ran the application.

This was as expected.

I then went back to the PC, and executed the exact same test_myDLL.exe as I had just copied to the device and IT RAN PERFECTLY.

I don't understand this.

Regards,
Jim

[dzt]

If you use optimised compile your device EXE will run on your desktop also. Non optimised EXE will not.

.NETCF is a subset of .NET so targeting .NETCF and staying inside the borders (do not P/Invoke for example) lets your DLL to be compatible with both device and desktop.

.NET EXEs are not platform/processor dependent (a kind like java but not exactly the same)

[obrienj]

dzt,

Thank you for the explanation, I thought I was going bonkers as it was not what I expected to be the case.

But having a common denominator is a good thing in some cases.

This has been fun. I guess it's what keeps me playing with computers long past my retirement. But over a 45 year career, I always enjoyed learning a new system or language.

I did notice that policing of what is and is not supported isn't all that good in either .NET or #develop.

For example, System.Threading.Mutex defines that creating a named Mutex in .Net CF isn't supported, yet if I target Net CF 2.0 (only one I tried), it compiles with no issue. I realize that the doc on MSDN maybe wrong, but either way it makes it a bit of a guessing game.

Have you had this experience?

Regards,
Jim