floele

Hm...I'm a bit reluctant to duplicate those controls of the application dialog. But you made nice suggestions and I'll look into it

From dl.htm? Because there is client side scripting taking place and Ketarin can't emulate that.

1. I'm not using any specifc font. Usually, it will result in mS Sans Serif or Segoe UI, size 10. 2. Just check some of those already used in templates.

Why would you want to do that? You can actually derive the getfile.php-URL from the dl.htm-URL without even looking at the content of the URL. It's no challenge because there is no challenge here.

Just the GUI point of view.

How else would you put all placeholders into one window?

I think that it migt look quite ugly if you have multiple placeholders with huge differences in length (especially with very long placeholder names).

The URL is hidden at the top of the page's source code: <script type="text/javascript" language="JavaScript"><!-- window.onload = function init() {urlquery=location.href.split("?"); var lnk="getfile.php?"+urlquery[1]; document.getElementById("lnk").href=lnk; frames['dl'].location.href=lnk;} //--></script>

Right now, everything related to updates should already be present in the log. I don't want to spam my source code much further with logging now. If there is something especially useful, I'll do, but that's it.

Yeah, he'd had to. But the text box would already be populated with that value. He sees your suggestion and can then decide wheter or not he likes that.

I'll add a new attribute for placeholders in Ketarin 1.0.3. Then you can do the following: <TargetPath><placeholder name="Target path" value="{root_folder}\{category}\{appname:replace: :_}_v{version:replace: :_}.{url:ext}" /></TargetPath> Seems most user friendly to me.

I'd only a referrer issue. Wrong referrer = latest version, right referrer = any version. No magic behind that and nothing that Ketarin couldn't work around.

Ketarin doesn't know any warnings...there are only errors

I don't know what Orbit downloader sends as HTTP request. You could use some kind of HTTP debugger / traffic watcher to check on that.

Nope. The only more "verbose" level of debugging is to compile Ketarin with Visual Studio and go through every step.

Well...I tried them, and they download the exact same version.

Which two app entries are it? You've posted quite a lot of XML during the past few hours and I've lost track somewhat.

Sorry, but I see nothing wrong with the application in your last post. Everything behaves as expected. Please tell me what exactly is wrong in your opinion (except for the missing log entry).

Oh, really? Well, you don't have to...but if you want to try, I'm available on IRC, Jabber, ICQ or MSN. Anyway, since I'm going to sleep now let me answer that so far, I see no two different behaviours. There is just one, that is, Ketarin downloads 1.0.1, no matter which URL you choose (this is not Ketarin, Firefox will do that as well). *Only* if ketarin.canneverbe.com is your referrer, you are free to download any of those files (Firefox does of course submit a referrer). I don't think that you should wrack your brain over this special situation which I created on my server, if you use the intended download URL for Ketarin you'll get your updates properly.

Erm...I feel like it makes more sense to discuss this per IM. This back and forth in the forum seems a little cumbersome...

The order of update checks is: - exists? - CIV - MD5 / FileHippo - Date / Size If you need some place to upload files for testing, feel free to use the wiki. I think you should be able to upload files there. Also, note that in older versions of Ketarin, the CIV was not working properly (did never detect any updates). Maybe you've suffered from that.

Yep, it should, and this is actually the result I get when I try your XML. And from what I can see, it did also download this file when you tried it (PreviousLocation)?

Nope, I'm not. These downloaders you use probably guess referrers. The XML files are not meant for restoration, but for interoperability. I really don't want to put any (or rather, further) "local" state information into it. Nope, I cannot. The state will be saved independently of whether or not there is a difference in contents.

That's a server side issue, as I said. Use a referrer to prevent that behaviour. For the XML: Consider user Alice and Bob store Ketarin to c:\Ketarin.zip. Now Alice exports her XML (using CIV) for Bob, since Bob wants to have her definition of Ketarin, because it is more *whatever*. Bob has still Ketarin 0.9, Alice already downloaded 1.0 before. Now Bob does not detect any update after importing Alice's XML, because it contains "1.0" as previous variable content, which is correct for Alice, but not Bob. The correct behaviour is to ignore the variable content for the first time, and instead use the file date / size as indicator. Once the file is up to date (using this kind of comparison), Bob will have "1.0" as previous value to prevent any further updates (for now), which is again the correct behaviour.

Currently, variables are "spotted" using regular expressions. These are not powerful enough to correctly analyse strings with escape sequences.