Op Fri, 13 Jan 2017 06:41:10 +0100 schreef Wolf <w...@wlenerz.com>:
there ae 2 versions of DM : DM5_obj and DM5_int_obj , the problem only
seems to arise on the..int version, use the other one instead.
Minor point is that only the _int_ version has been patched for GD2.
I just installed both versions in SMSQm8 and both reported the date error
but now my PC clock was not upset, nor by OK on the given date.
There was a Qlib error next on "Q_ERR_ON"(?)- both versions and Qlib_run
was installed - but a Continue did start the program.
Then there was a running error on the FEX keyword, which is expected to be
an FI2 command but may have been disabled while the SMSQ/E command does
something completely different.
To resolve both issues the sources are needed so I think it's wise to
avoid DM5 until this is resolved.
Earlier I had patched my copies of DM5 and FI2 to read FFX instead of FEX,
which worked until the date problem arose.
On 12/01/2017 17:47, Martyn Hill wrote:
Just to confirm that I too have been unable to run DM5 on QPC (v4) and
saw oddities around the date before it would hang QPC.
I didn't investigate to the same depth, but it appears to match your
On 12/01/2017 15:35, Bob Spelten wrote:
I was trying to get DiskMate5 to run in QPC2/QLE but ran into a
It reported a wrong date but while the suggested date was correct my
PC clock had been reset in the background to 18-Jan-2053, causing
problems on the W$7 side.
In my QPC2/QLE this also froze SMSQ/E but not in my normal QPC2.
Also a previous QPC2 (v3.40/3.16) behaved the same.
I have used DM5 for GD2 sporadically before but never seen this bug.
Has something changed in SMSQ/E's date handling that is not working
for DM5 anymore?
Has anyone experienced this before?
The BSJR QL software site at: "http://members.upc.nl/b.spelten/ql/"
QL-Users Mailing List