Martin C

It is my understanding that UBot 5 no longer supports the /auto facility, you either have to use the in built scheduler, which is suitable for some but definitely not all situations, or if you have the developer edition I think you will be able to use the "on load" command to achieve the same thing.

I have a virtual server running XP if I could work out how to get a Windows 7 license and how much it would cost I might think about upgrading but every time I have looked I have disappeared into a dark, deep labyrinth of Microsoft licensing jargon and terminology that seems to indicate it might be cheaper and more straight forward reverting back to having physical multiple machines, so not so much of an XP die hard here more of a exasperated understanding Microsoft licensing person.

Am I right to assume that as UBot 5.5 requires .net 4.5 that it will not be possible to deploy compiled Ubots on a Windows XP platform?

Although a laptop is fine for developing Ubots when they are run in a production environment the majority of Ubots that I develop are better suited to being run on a server. I use a VM server that allows me to allocate specific machines to specific tasks. In my experience if you are into any type of development the fastest processor and the most memory you can afford is the way to go. In my book they haven't yet developed a processor that I would have said is quick enough.

I'm not proficient with Java but if anyone has any method that would work it would be appreciated.

Thanks, I'll check it out but I think I really need something that will work with threads, also that will preferably spoof the size rather than physically change it.

Unless all the bug items are being worked on simultaneously, which is very unlikely, I would be more reassured if there was a new release every month with 5 to 10 bugs solved each time, that would at least demonstrate progress.

A little bit of substance behind that comment would be useful, I suppose a road map of planned releases would be too much to ask. I would like to know if I am expected to go another year without a working product or if I should follow rogeradvanta's example and stop the maintenance until there is a product to maintain. Isn't a year long enough? It's the silence that is killing me doesn't anyone know anything about customer service, Chapter 1, communication?

I know back in the heady days of UBot 4 that there was a "set browser property" command that in theory allowed you to spoof the browser screen size. I think it was withdrawn until a better solution could be found probably at a time when quality was a concern. I also am aware that there is a year old feature request to have the same functionality made available in UBot 5. I'm going to guess that while the UBot 5 core features are in need of work, expecting a new UBot 5 feature to be made available is just fantasy, and anyway I need it to work in UBot 4 until such times as UBot 5 is usable.

I've had a few post deleted from the forum myself when I have not been able to resits the odd barbed comment (normally wholly directed at UBot 5's lack of progress), which is a shame because the majority of people on this forum have an investment and want Ubot to do well. I dislike forums that censor negative comments, more so when it is totally justified. I remember many moons ago I was invited to an application user group meeting because I was looking at investing in the software. It was an early document flow management system written by the now defunct Digital. It looked really good on p

It is coming up to a year now since Ubot Version 5 was launched and maintenance support for Version 4 ended. There seems very little communication from the Ubot team as to what is happening with version 5, the updates have more or less dried up and I find that it is still too bug ridden to be useful. Are people still paying their maintenance because I after a year I am seriously contemplating whether to cancel the maintenance until such time that version 5 is a robust production tool? With hindsight version 5 was never ready to be released, but having been released there seems to be very

Whoa - hang on since October 2013 I have been paying for support and updates for a product I can't currently use so I really don't fancy paying any more because the servers are unreliable and need 24/7 support. Quite honestly if an organization can't monitor their servers 24/7 at a negligible cost with the technology that is available today it says a lot about the organization. I don't know the details of what caused the two recent server outages but I run 24/7 websites, we receive automatic notification if any of the sites becomes unavailable and it is very rare that we can't fix, or at le

Changing the user agent isn't going to help, a responsive design will adapt to a PC browser window being shrunk or enlarged. There is no website=responsive HTML statement and there is more than one way to make a website responsive so I think the answer is "Not Easily", it could be a case of examining the css but although someone could look at the css and almost instantly determine if it were responsive or not I am not sure how easily you could do that programatically. In addition there are websites where being responsive doesn't work and that they have to have a mobile version, a good examp

One that adapts the design of the website to match the device that the website is being viewed on.

If V5 came out last October and it is 4-6 months away from being usable (and judging from the lack of progress that timescale seems optimistic), it makes continuing to pay for support and maintenance difficult to justify.