dllToDate stating point

agraham said:

In general they are either desktop only like ControlsExDesktop or for both, in that a device specific library like ControlsExDevice will in fact include a desktop dummy of limited functionality like ControlsExDevice Dummy to allow desktop development. Therefore in practice I think that you can regard a library archive as an individual entity and not worry about its intended target.
No matter what I do with the contents I keep any downloaded archives (mainly dzts) in a single archive folder and extract them any time I want to reference them. So in my case just scanning that folder will tell whether I have downloaded the latest version.
I seem to remember that Cableguy implied in a previous post that Erel doesn't want any automatic downloads happening.

Click to expand...

I thought the discussion was that he didn't want automatic updating in the background (kind of a continuous check & update, or something scheduled like Windows update)

However, automatic updates would be a user configuration. By default, the program would not update automatically. And if it's not something that anyone wants, I'm not going to spend any time coding for it.

I ask about platform versions because a future release might run from the mobile device. It wouldn't make sense to check and download something that is specific to the PC.

Cableguy said:

My next step was going to be creating a sub that, before exiting the firstrun, would go trought the libraries folde and create a list of all the existing libraries...
I can create and maintain a xml like file on the dll listing thread...
I can even go through the older dlls in order to retrieve the xml data..
But I need US to concour in a xml format...
This way, instead of going trough all the dll listing post and parsing it, it would only require to download the xml file and compare withe the lattest one on disk...

As I posted before... my xml file example would be something like...

B4X:

<Client Side xml file>
   <Total Dlls>2</Total Dlls>
   <Dll 1>
      <Name>Here we put the dll name</name>
      <Version>1.0</Version>
      <Description>Here we make a simple description of the Dll</Description>
      <Download URL>www.b4x.com\Forum........</Download URL>
      <Desktop Dll File>xpto-desktop.dll</Desktop Dll File>
                <Device Dll File>xpto-device.dll</Device Dll File>
      <Desktop CS File>xpto-desktop.cs</Desktop CS File>
                <Device CS File>xpto-device.cs</Device CS File>
      <Help File>xpto.chm</Help File>
                <ExtraFile1>extra.img</ExtraFile1>
   </Dll 1>
   
   <Dll 2>
      <Name>Here we put the dll name</name>
      .
                .
                .
                .
                .
   </Dll 2>
   .
   .
   .
   .
   .
   .
   </Client Side xml file>

No extra work for developers, except the indicating me, what files to extract to libraries folder

Click to expand...

Andrew mentioned that he copies the zip to a directory on his pc, and extracts from there. In that case, I'm not sure what benefit there is in an xml file when you can unzip from a known directory into the B4PPC library.

I think xml has some potential, but I don't see any library authors helping maintain any unless there is a big reason to do so. I'd hate to see everything dumped on you to maintain the forum and all of these xmls.

I thought the discussion was that he didn't want automatic updating in the background

Click to expand...

I thought, possible wrongly, otherwise. Better check with Erel to get the definitive answer.

I ask about platform versions because a future release might run from the mobile device. It wouldn't make sense to check and download something that is specific to the PC.

Click to expand...

From comments in private email exchanges with Erel it would seem he thinks (and for what little it is worth I agree) that the future trend for Basic4ppc apps is optimised compilation. As, for technical reasons, this cannot be implemented on the device then for the foreseeable future there will always be a desktop equivalent for every device library and the desktop IDE will be essential for producing compiled apps. As well as permitting a degree of desktop development for a device specific app this matching library is also a requirement for optimised compilation, I won't bore you by attempting to explain why (but if you really, really want to know ... ).

agraham said:

I thought, possible wrongly, otherwise. Better check with Erel to get the definitive answer.
From comments in private email exchanges with Erel it would seem he thinks (and for what little it is worth I agree) that the future trend for Basic4ppc apps is optimised compilation. As, for technical reasons, this cannot be implemented on the device then for the foreseeable future there will always be a desktop equivalent for every device library and the desktop IDE will be essential for producing compiled apps. As well as permitting a degree of desktop development for a device specific app this matching library is also a requirement for optimised compilation, I won't bore you by attempting to explain why (but if you really, really want to know ... ).

Click to expand...

Does the optimised compilation have to do with how I can run some programs compiled for my mobile device on my PC (since I have CF 2.0 installed)

digitaldon37 said:

Does the optimised compilation have to do with how I can run some programs compiled for my mobile device on my PC (since I have CF 2.0 installed)

Click to expand...

That is not a feature of Basic4ppc but is built into the .NET Framework. A .NET application is not (usually) processor dependent because it targets a virtual machine and is compiled to native code as it is run. Also the Compact Framework is as far as possible a sub-set of the full .NET Framework. Because of this a Compact Framework application can run on a desktop as long as it, or any libraries it uses, do not have any device dependencies.

Hi all...

I've added a file, "DLL2Date.txt", to the first post of the Dll Listing thread.
This is a test file and is of no use to any one, except for me, for testing purposes...

I've decided to return to the DLL2Date project, and take it from were I left it...
Thank you Don, for the availability, and hope you can understand why i'm coming back to this...
Thanks you all for your positive feedback these past days...
__________________

Another "in test feature" introduction...
Client side dll list creation is now working..

As it is a "in test" feature, it gets executed everytime you run dll2date...

I goes to the given (in settings) dll dir, and lists all the cs files...
This aproach may be wrong, but it is the most eficient and secure way to retrieve aditional info about the dll..
I've come to notice that EREL alway puts the version of the dll in the first line of the cs file...
So I make 2 sugestions to all dlldevelopers...
1-use EREL's way and add the "//Version: x.xx" in the first line of your cs file...If no version line is present, the dll will NOT be considered...

2- I coded some "description fetch" wich looks at the 2nd line of the cs file for a "//description: bla bla bla bla bla"...This will be used later maybe as a tooltip text or similar...so a SHORT SIGLE LINE description if any.
If no description is detected then the line "Description not available will be added..

Yes, I know that for some, changing you're cs files is something you do NOT wish to do...
But it IS for a greater good, and it takes only a minutes each file...and you still have plenty of time to do it, as this is going to be slow in development..

Again, comments, sugestion, anything is welcomed..

Cableguy said:

I've come to notice that EREL alway puts the version of the dll in the first line of the cs file

Click to expand...

It's in all (maybe most!) of mine too. That's what the optimising compiler uses to tell you which version of the library it has merged with the exe in the message box it shows at the end of compilation.

agraham said:

It's in all (maybe most!) of mine too. That's what the optimising compiler uses to tell you which version of the library it has merged with the exe in the message box it shows at the end of compilation.

Click to expand...

Cool, so can you at least think about implementing the 2nd?
As in the kevin Costner's field of dreams...
" you you..."do this..."They will..." too!

side note:
How can i make my webbrowser to merge in the exe?
it's made of 2 cs files...
I've used notepad and merged into 1, sugested by EREL, but still no luck...

Cableguy said:

Cool, so can you at least think about implementing the 2nd?

Click to expand...

Not a good idea I think. You can't use line 2 anyway. That is reserved for a "//unsafe" line to allow for compiling code that needs to be flagged unsafe and/or for one or more further lines can follow defining "//ref: xxxx" references to other libraries in the Libraries folder that need to be referenced. Also I was considering suggesting to Erel a further option for a "//inc: xxxx" flag to allow multiple cs files to be merged.

How can i make my webbrowser to merge in the exe?
it's made of 2 cs files...
I've used notepad and merged into 1, sugested by EREL, but still no luck

Click to expand...

As long as the single cs file compiles OK it is likely that the name of it is not the same as the name of the dll. MyLibrary.dll must have MyLibrary.cs in the Libraries folder to merge. The lack of a "//version: x" line doesn't matter.

agraham said:

Not a good idea I think. You can't use line 2 anyway. That is reserved for a "//unsafe" line to allow for compiling code that needs to be flagged unsafe and/or for one or more further lines can follow defining "//ref: xxxx" references to other libraries in the Libraries folder that need to be referenced. Also I was considering suggesting to Erel a further option for a "//inc: xxxx" flag to allow multiple cs files to be merged.

Click to expand...

This I didn't know..need to come up with another way to get the description or simply drop it...

As long as the single cs file compiles OK it is likely that the name of it is not the same as the name of the dll. MyLibrary.dll must have MyLibrary.cs in the Libraries folder to merge. The lack of a "//version: x" line doesn't matter.

Click to expand...

I did not compile, I just took both cs files and "merged" them using notepad...then copied them to the libs folder...
I'll get a better look at it in a day or too...
I'm having my last PC minutes, as i will be withou PC for a day or two...while moving back to my....other house...

EDIT:
its been a good coding day... got this bit working, and am now able to merge my former 2 cs file dll into a single cs file and merge the dll in the exe during compilation...