Market Discussions

For those who don't know, Hel O'Ween has stopped supporting EveWalletAware as per this post. This is a true shame, as I've never found a comparable program for recording and analyzing personal and corp market data.

Just as the old forums were shut down, users were having trouble using EWA's last version, which uses the new CAK API system. No one seemed to be able to properly enter and save a new key. The only solution found at the time required starting fresh with a new database, which was a pain because many of us had accumulated rather large databases of historical data. I was just playing around with the .mdb file, contemplating manually copying all my old data into a new database, when I noticed that running the program with the old database was strangely pulling my account balance despite my not having successfully entered a valid new API key.

A quick look inside the table [banav_tEveAPIKeys] showed me both why that was, and why no one could enter and save new keys. Turns out that the old keys were still in this table, with one marked as default. The program's front end could no longer properly read these old keys and thus didn't recognize them, so when trying to save a new key as default was failing. Deleting all the old-format keys from this table solved the problem entirely, and I can now use EWA fully again, with my old data intact.

That's the good news. The bad news is that eventually new patches are going to permanently break EWA's database relevance.

What are our options?

just let it die...

EWA relies on a programming environment that has been outdated for 9 years now (and is officially not supported by Microsoft since April 08). You will have a hard time just getting your hands on the compiler/IDE, nevermind finding someone who is still well-versed in VB6 and its schizophrenic approach to OOP.

Then you have the beautiful statement "However there are no plans to include VB6 runtime in future versions of Windows beyond Windows 7." which you can read however you would like to.
Maybe the runtime will just not be shipped with Windows 8 by default, maybe it will not be supported by Windows 8, maybe it will be broken with Windows 8? who knows...
In any case there is no assurance that VB6 applications like EWA will even be able to run under Windows 8.

Add to that the can of worms that is storing all data in an Access database...


Anyone forking or taking over this project would probably end up rewriting the whole software in VB /C#.NET using a SQLite backend (as EMMA has shown that a fully-fledged SQL server - while nice for the developer - causes issues for many users and MSSQL CE is terribad) sooner rather than later.

And while you might value being able to continue using (or port over) your old database this "feature" would only tie the hands of whomever dares to write a completely new piece of software with similar features as EWA (call it "EWA 3") but using contemporary tech. Just not worth the effort and might result in bad design decisions if done.

edit: forums ate my original post

VB6 is unsupported, period. Anyone wanting to help out with EWA development would have a hard time finding a VS6 license to buy.
my quote on the runtime is taken from http://msdn.microsoft.com/en-us/vbasic/ms788708 and I don't know of any official word saying otherwise.

"core Windows (8) API" meaning WinRT? my impression was that the first-class way of calling this API was through "projections" even when using native C++ (and VB6 would not have access to these bindings due to the different metadata format).

Python would be a good choice. But even Python isn't good without a framework like QT or wxWindows. I propose web2py because it's really easy to handle, without the hassle of handling events, webbased and everyone is able to start the buildin webserver, when it's not used together with Apache. As a benefit we are able to access more than one database type. For most of us, it's OK wth sqlite. PostgresQL, MySQL and other DB's are easy to use. The only hassle with web2py is, that you have to use win32 extensions for windows, when you want to run "cron" services. So windows can't run with 64bit Python, but this not really a disadvantage.

I made with this framework a maintenance software in only 2 weeks. I would help programming such a software if there are more volunteers.