-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
How to create a Basic4ppc library
- Thread starter Erel
- Start date
- Similar Threads Similar Threads
Cableguy,
That's my problem.
When I go to the MS website looking for the referenced SDK, Microsoft .NET Compact Framework 2.0 SDK, there doesn't seem to be such a thing. Any time I find a reference to that name and link to it, I get shown the Microsoft .NET Framework 2.0 SDK (x86).
I already have installed:
Microsoft .NET Compact Framework 2.0 SP2
Micorsoft .NET Framework 2.0
which I believe are correct.
It's the SDK that is baffling me, I just can't seem the find the one referenced.
These .NET distribution are making me bleary eyed. Or it could just be adding one too many programming languages to the list fo 25-30 learned over 45 years.
Cableguy, if you could point me to the requsite SDK, I'd appreciate it.
BTW, are nCOver, FXCop, and SVN????? also needed as documented.
Regards,
Jim
P.S. Where in Portugal are you? I've spent some wonderful days in Lisbon on business trips.
That's my problem.
When I go to the MS website looking for the referenced SDK, Microsoft .NET Compact Framework 2.0 SDK, there doesn't seem to be such a thing. Any time I find a reference to that name and link to it, I get shown the Microsoft .NET Framework 2.0 SDK (x86).
I already have installed:
Microsoft .NET Compact Framework 2.0 SP2
Micorsoft .NET Framework 2.0
which I believe are correct.
It's the SDK that is baffling me, I just can't seem the find the one referenced.
These .NET distribution are making me bleary eyed. Or it could just be adding one too many programming languages to the list fo 25-30 learned over 45 years.
Cableguy, if you could point me to the requsite SDK, I'd appreciate it.
BTW, are nCOver, FXCop, and SVN????? also needed as documented.
Regards,
Jim
P.S. Where in Portugal are you? I've spent some wonderful days in Lisbon on business trips.
That should be correct as its MUST be installed in a desktop...(X86)...
Anyway I made a simple search for ".Net" in The M$ Download Center, Here are the results
Yes, and they should be enough for most cases...
SDK is only needed,(I THink) if ou intent to do some "Include" in our DLL's...
Still, if you are targeting other versions of .NET, THEY MUST ASO BE INSTALLED, as .Net 1.0, .Net 1.1, etc...
Cableguy, if you could point me to the requsite SDK, I'd appreciate it.
Never needed them....
Try my Location Coordinaes in google maps...
or find me in our comuniy map,a nd you will see that I'm a Northenrn man, from a city near OPorto..
Cableguy,
Thanks for all the help. I've got everything in place and have sucessfully compiled for the PC both the DLL and B4P parts of a sample named MyDLL found in somewhere in this tread.
Next I want to do the same for the my device but am still searching how to do compile the DLL for the device with #develop. I've already figured it out for B4P and have compiled that part of the sample for the device.
Next, I plan to build .NET based versons of some services I've developed in other languages to do serialization (MutEx), events (Event), and file mapping (Shared Storage, needs NET CF2.0). I hope to build all for both the PC and device.
For what I'm doing I need that kind of IPC support between processes and in a few cases, threads.
Again thanks for the help.
Regards,
Jim O'Brien
Thanks for all the help. I've got everything in place and have sucessfully compiled for the PC both the DLL and B4P parts of a sample named MyDLL found in somewhere in this tread.
Next I want to do the same for the my device but am still searching how to do compile the DLL for the device with #develop. I've already figured it out for B4P and have compiled that part of the sample for the device.
Next, I plan to build .NET based versons of some services I've developed in other languages to do serialization (MutEx), events (Event), and file mapping (Shared Storage, needs NET CF2.0). I hope to build all for both the PC and device.
For what I'm doing I need that kind of IPC support between processes and in a few cases, threads.
Again thanks for the help.
Regards,
Jim O'Brien
How to organize for dual platform development
Now that I seem to have all the development pieces (B4P, #develop, and .NET 2.0 (Win32 and CF)) I'm curious about anyone's thoughts on how to organize project directories to handle building of C# and B4P components for dual platforms, in my case a PC and an HTC Mogul running WM6.
Any additonal question is how, in both #develop and B4P, to setup project definitions to allow for simultanous development such that any change to the source will be reflected in all target platform components. My assumption here is that the source for a given project will be common across platforms.
Anyone got any ideas on this?
Regards,
Jim
Now that I seem to have all the development pieces (B4P, #develop, and .NET 2.0 (Win32 and CF)) I'm curious about anyone's thoughts on how to organize project directories to handle building of C# and B4P components for dual platforms, in my case a PC and an HTC Mogul running WM6.
Any additonal question is how, in both #develop and B4P, to setup project definitions to allow for simultanous development such that any change to the source will be reflected in all target platform components. My assumption here is that the source for a given project will be common across platforms.
Anyone got any ideas on this?
Regards,
Jim
From the main help file:
So you can set the app by cheking if it is running on the device, if not its on the desktop...
So you can set the app by cheking if it is running on the device, if not its on the desktop...
B4X:
.......
If cPPC= True then RunOnDevice Else RunOnDeskTop
.......
Sub RunOnDevice
'Set the app to run on the device
......
End sub
Sub RunOnDeskTop
´Set the app to run on DeskTop
......
End SubActually I'm not as concerned about execution time as much as I am how to build and store the execution components (*.exe and .dll) for each platform from a common source in the easiest most effective way.
If I can't build from common source then so be it but I'd really like to.
Or am I missing something relative to Cableguy's post. I didn't think that in B4P I had to consider which platform I was running on. I'm pretty sure I don't in .Net except where .Net the PC and .Net for CF don't share common class defintions. Did I miss something?
Regards,
Jim
If I can't build from common source then so be it but I'd really like to.
Or am I missing something relative to Cableguy's post. I didn't think that in B4P I had to consider which platform I was running on. I'm pretty sure I don't in .Net except where .Net the PC and .Net for CF don't share common class defintions. Did I miss something?
Regards,
Jim
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"!
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"!
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
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
Yes, let's...
Yes, very.
As I sayed before, any DLL targeting the Compact(ed) FrameWork, WILL run on bothe platforms.
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.
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.
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
But you said one thing that I don't completely understand.
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
Last edited:
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...
Thank's, i will try..
Hope your's is twice as good...
Happy codding!
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
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
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.
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...
Cableguy,
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
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
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)
.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)
Last edited:
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
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