dllToDate stating point

M

Mr_Gee

Active Member
Licensed User
Longtime User
I also tried this but i entered the wrong password :)
where it this information stored so i can delete it?

also I noticed connection spelled wrong ;-)
 
Cableguy

Cableguy

Expert
Licensed User
Longtime User
@Mr_Gee: I have PM'ed you...
 
Z

Zenerdiode

Active Member
Licensed User
Mr_Gee said:
also I noticed connection spelled wrong ;-)
Click to expand...

...and 'Established' :signOops:

I also may connect now. Can't wait until it checks my dll's :)

EDIT:

I've tidied up the English.lng file. Obviously you'll have to rename the extension from .txt.
 
Last edited:
M

Mr_Gee

Active Member
Licensed User
Longtime User
Cableguy said:
@Mr_Gee: I have PM'ed you...
Click to expand...
Thanks, it worked :)
and I was able to get connected this time, great job!

Cableguy said:
I intend to also make this app a background-running app, wich will check for updates at a given time,
Click to expand...
I hope there will be an option so it can be turned off..

Why you ask, I have the application on my work laptop, and I don't want to generate too much internet data
Cableguy said:
and This will not work with an USB stick based B4ppc, unless you make sure the USB stick is present or have a desktop based Dll folder...
Click to expand...

It would be very nice to also get USB installs working with this,
How about have the app check the install directory for a specific file,
lets call it "SaveData.ini" if available it will use that file for reading/writing the settings that are currently in the registry, the Dll Path would be relative to the AppPath.
You could even use a SQLite DB together with MD5 if you want it to be secure :)

again great job!:sign0188:
 
D

dennishea

Active Member
Licensed User
If I understand post #1 right I ran program and it took information and quit. Then I ran it again and it authenticated everything. I am running on a Dell Latitude d600 laptop with Xp Pro sp3. Everything seemed to work fine.

Denny :) :sign0188:
 
Cableguy

Cableguy

Expert
Licensed User
Longtime User
dennishea said:
If I understand post #1 right I ran program and it took information and quit. Then I ran it again and it authenticated everything. I am running on a Dell Latitude d600 laptop with Xp Pro sp3. Everything seemed to work fine.

Denny :) :sign0188:
Click to expand...

Yes that is the correct current prcedure...
 
Cableguy

Cableguy

Expert
Licensed User
Longtime User
Now that the Authentication method seems to work for everybody, It's time to start withe the real job of keeping our dlls up to date....
We will need to implement some guidelines to both releases and creations of the Dlls...
I was thinking of using a xml file to keep track of the current installed dlls, but I need to setup a standart so that retrieving info would be easy...
1st - All Dlls should have a "Version" Propertie, and most do, but there are still some that don't...
2nd - All releases must contain only 3 files :
-The .dll
-The .cs
-The .chm

These are the files that trully are important for this to work properly...

Demo files should be posted in an seperate zip file...

Please tell me what you think about these guidelines
 
D

digitaldon37

Active Member
Licensed User
Longtime User
Cableguy said:
Now that the Authentication method seems to work for everybody, It's time to start withe the real job of keeping our dlls up to date....
We will need to implement some guidelines to both releases and creations of the Dlls...
I was thinking of using a xml file to keep track of the current installed dlls, but I need to setup a standart so that retrieving info would be easy...
1st - All Dlls should have a "Version" Propertie, and most do, but there are still some that don't...
2nd - All releases must contain only 3 files :
-The .dll
-The .cs
-The .chm

These are the files that trully are important for this to work properly...

Demo files should be posted in an seperate zip file...

Please tell me what you think about these guidelines
Click to expand...

I think we need a unique identifier, version, author, a description, a chm, a desktop dll, a desktop cs/vb (if available), a device dll, and device cs/vb (if available)
 
Cableguy

Cableguy

Expert
Licensed User
Longtime User
digitaldon37 said:
I think we need a unique identifier, version, author, a description, a chm, a desktop dll, a desktop cs/vb (if available), a device dll, and device cs/vb (if available)
Click to expand...

Yes, Author, version and Description, provided by the Author, Will be part of the Xml, but What I was talking about is the "Dll package"...
The rest is added in the xml, and then retrieved by the App
I will try to get something working and then we can take it from there...
Again, my coding Time per day is sometimes limited, so a new 2release may only appear next weekend...
This will take its time to develop, but in the end, I hope it will make our life easier..
 
agraham

agraham

Expert
Licensed User
Longtime User
Cableguy said:
All releases must contain only 3 files ... Demo files should be posted in an seperate zip file...
Click to expand...
Sorry, but I am not going to change my archive backup system (here on my network) which uses the single zip, as posted for a library, as the backup entity for a library release version, including any demos as they may change between versions. Anyway you should be able to manage with an arbitrary number of files in an archive and just look for the extensions you are interested in.
 
M

Mr_Gee

Active Member
Licensed User
Longtime User
Paulo,

Why don't you stick to the xml file that I used?
You would need 1 xml file per DLL, in there you would specify the required info (here, I tweaked the one I used a bit)
B4X: 
<dll>
<dllname>ImageLib</dllname> 
<dllauthor>Erel</dllauthor> 
<version>1.00</version> 
<dlldescription>Allows you to minipulate images</dlldescription>
<dllhelp>http://www.b4x.com/help/imagelib/index.html</dllhelp>
<item>ImageLib.chm</item>  
<item>ImageLib.dll</item>  
<item>ImageLib.cs</item>  
<item>ImageLib.sbp</item>  
</dll>
I'm not sure where you see the location of the file, I'm assuming in the forum, you could in that case include the file's URL (if it stays the same after an update) in this file, then you have everything in one go.

the author would only need to update this xml file when a new version is created...
 
Cableguy

Cableguy

Expert
Licensed User
Longtime User
@Mr_Gee
1 xml file per dll is not a good solution in my opinion...
Using your xml as a template, all dll coul be listed there, in a single xml file...
I'm at work now, later today I'll post my "solution" xml...

@Agraham
Your .zip files are the most complete zip file I've seen in this Forum, and offer very important information, but, thinking a bit on the user side of the dll2date, this generates a great amount of internet traffic (a few hundreds Kb), just to retieve a smal amount of relevant data (a few tens of Kb).
 
D

digitaldon37

Active Member
Licensed User
Longtime User
Cableguy said:
@Mr_Gee
1 xml file per dll is not a good solution in my opinion...
Using your xml as a template, all dll coul be listed there, in a single xml file...
I'm at work now, later today I'll post my "solution" xml...

@Agraham
Your .zip files are the most complete zip file I've seen in this Forum, and offer very important information, but, thinking a bit on the user side of the dll2date, this generates a great amount of internet traffic (a few hundreds Kb), just to retieve a smal amount of relevant data (a few tens of Kb).
Click to expand...

Speaking from the point of view from a user (who is anticipating having a systematic way of keeping dlls up to date) I think any system is going to have to work with how the largest number of libraries are kept (which seems to be agraham's libraries)

I am not sure how the remote files will be managed but if I look at agraham's XML library I have the following information to consider:

Forum post: http://www.b4x.com/forum/additional-libraries/3385-xml-library.html#post19094

Zip file: http://www.b4x.com/forum/attachments/additional-libraries/2648d1227286407-xml-library-xml1.1.zip

Locally, the zip file has 1 dll, 1 chm, 1 cs, and 1 sbp. The client needs a way to know what files should be extracted for each platform (in this example, they work on both platforms).

My question is how to map the local version (use the dll version method, which not everyone has implemented) to the remote file name, which doesn't always contain the version number in the zip file name? How do you know when the remote file is more current than the local one?

Just my observations...
 
Cableguy

Cableguy

Expert
Licensed User
Longtime User
digitaldon37 said:
My question is how to map the local version (use the dll version method, which not everyone has implemented) to the remote file name, which doesn't always contain the version number in the zip file name? How do you know when the remote file is more current than the local one?

Just my observations...
Click to expand...

By mantaining a xml file with that info in the dll listings...
 
D

digitaldon37

Active Member
Licensed User
Longtime User
Cableguy said:
By mantaining a xml file with that info in the dll listings...
Click to expand...

Hi Cableguy,

I guess I meant how do you differentiate if agraham were to always upload his zip as "XML.zip" instead of "XML1_1.zip" on the remote server? In reality I don't think he does, but I did notice that one of your libraries had no version number in the zip name. Will you be storing XML files on the remote server (basic4ppc.com/forums) with this information?
 
Last edited:
Cableguy

Cableguy

Expert
Licensed User
Longtime User
This would be my suggestion to a Cllent side xml, and the only diference between the server side file would be the "header" and the file name..

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>
      <Dll File>xpto.dll</Dll File>
      <CS File>xpto.cs</CS File>
      <Help File>xpto.chm</Help File>
   </Dll 1>
   
   <Dll 2>
      <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>
      <Dll File>R2D2.dll</Dll File>
      <CS File>R2D2.cs</CS File>
      <Help File>R2D2.chm</Help File>
   </Dll 2>
   .
   .
   .
   .
   .
   .
   </Client Side xml file>
I Know my syntax is wrong but this was just to give you guys an idea of the elements i think should be in the xml, and how the listing would apear..
What do you think?
 
Last edited:
M

Mr_Gee

Active Member
Licensed User
Longtime User
to be honest, I think you are going to regret it in the long run...
If I were you I would not name the different items :
<Dll File>R2D2.dll</Dll File>
<CS File>R2D2.cs</CS File>
<Help File>R2D2.chm</Help File>
I'd just use <item> and run through each of them..
using your way, you limit yourself to 1dll and 1 cs file ,if there are several libs with extra files, the FMOD lib has a extra fmodce.dll, also the flash lib has several dll's, dzt's minimize lib (cant remember the name atm) has an icon which needs to be in the B4P folder during testing.

The reasons why I went for 1 xml per Lib was because App2Date also works like this, and that seems to work perfectly
 
Cableguy

Cableguy

Expert
Licensed User
Longtime User
Mr_Gee said:
to be honest, I think you are going to regret it in the long run...
If I were you I would not name the different items :
<Dll File>R2D2.dll</Dll File>
<CS File>R2D2.cs</CS File>
<Help File>R2D2.chm</Help File>
I'd just use <item> and run through each of them..
using your way, you limit yourself to 1dll and 1 cs file ,if there are several libs with extra files, the FMOD lib has a extra fmodce.dll, also the flash lib has several dll's, dzt's minimize lib (cant remember the name atm) has an icon which needs to be in the B4P folder during testing.
Click to expand...
I see your point, and I think I can work around that ADDING the Extra items, but I would rather keep the rest of the strutcture...
But keep in mind that extra dll files are not recongined by the IDE and for instance , if we add the flsah palyer dll to the objects, the other 2 files needed for the wrapper dll to work are not automatically copied... That's why its a wrapper and not a self contained dll...
I'm already working on a stand alone xml creator to enable dll creators to create their xml file piece and send it to me...thus getting also some work off my hands...
then I would just compile all the xml pieces into one...
Still I think that demo's image files and others, should NOT be copied to the libraries folder, so that the folder is kept clean...
 
Last edited:
M

Mr_Gee

Active Member
Licensed User
Longtime User
Don't get me wrong, I think it's great what you are doing, I just want to make sure you have thought of everything ;-)

Cableguy said:
Still I think that demo's image files and others, should NOT be copied to the libraries folder, so that the folder is kept clean...
Click to expand...

In regards to the above, I think all files that are required to get the lib working should be in the in the library folder,
so for the flash dll, it would be all 3 dll's (atm) and for DZT's lib it would be the dll + icon...
the demo stuff should not be in there..

but again that is up to you.
 
Last edited:
You must log in or register to reply here.
Top