Transferring From Xp To Windows 7

[embayweather]

Just transferred all my programs , data etc to a new machine running Windows 7. Can I use the old ctl file from XP or will it need to be re written? 

 

Thanks

 

Mike

[AzeoTech]

The .ctl files will run on any OS DAQFactory supports.  They are independent of the OS.  The exception would be in the very rare case that you used extern() to access a windows system DLL for some reason.  There are probably some other really obscure ways the OS could matter, but I can't think of them and I seriously doubt they apply to you.  Of course you will have to watch for paths for, say, logging sets, and things like ODBC setup.

 

The other thing issue I've seen with OS's has to do with accessing the registry.  On Win 7 I've seen cases where the logged in user rights didn't allow writing to the registry and thus blocked registry variables in DAQFactory.  If you use registry variables, check to make sure they will update under Win 7.  Otherwise, you'll either need to change your user's rights, or consider an alternative method of persisting variables.

[embayweather]

Thank you for your help with this. I will move the system across today.

 

Best wishes

 

Mike

[philb1]

I have the Registry access problem converting from WinXP to Win7 (Pro 64-bit).

My old program used a lot of registry variables and I'd like to get it running on Win7 with minimal changes.

 

I have installed latest V5.90.6 on Win7 running as Administrator (numerous times !), but it does not create the DAQFactory LocalMachine registry hive. Virus checking and Firewall were disabled once I noticed the problem, and tried again. Uninstalling and installing to a different folder did not help either.

Similarly starting DAQFactory as an Administrator will not let me read or write registry variables (as a test I copied over a .reg file from a Win XP machine; I can edit the LM\Daqfactory variables within Regedit no problem).

 

There appears to be no problem with registry permissions; any ideas ?

 

Thanks,

Phil

[AzeoTech]

The problem is you have to run DAQFactory as an admin (or in compatability mode) under 5.90 to get it to have permissions to write to the registry.  By admin I mean actually going into the properties and selecting the Compatability tab, then Run as Administrator.  It doesn't matter how you are logged into the system.  This is part of Windows enhanced security to require apps to run with elevated credentials even as admins.  Its connected with UAC, though turning off UAC does not fix this.  Note that it appears that it is compiler related, so this issue does not appear in 5.87a which was build on an older C++ compiler.  So you have three options:

 

1) stay in 5.87a (which may not be an option for you)

2) check Run as Administrator for DAQFactory.  Alas, that means UAC is going to display its warning every time, but you can always disable UAC (not really recommended, but an option)

3) change your code to not use registry variables.  I recommend using classes as described elsewhere in this forum, such as here:  http://www.azeotech.com/board/index.php?/topic/5406-general-daqfactory-questions/#entry19614  Skip to the posts #10 and 11 where it talks about CSettings.  And this post:  http://www.azeotech.com/board/index.php?/topic/5159-saving-variable-values/?hl=csettings#entry19212

[philb1]

The problem starts with the DAQFactory installer, it does not create the Local Machine \DAQFactory key.

I have run the installer elevated as you described, and the Windows Events log suggests installation has been succesful:

(Same situation with DAQFactory.exe)

 

  Information    2014-02-20 15:11:58    MsiInstaller    1033    None
  Information    2014-02-20 15:11:58    MsiInstaller    11707    None

  Log Name:      Application
  Source:        MsiInstaller
  Date:          2014-02-20 15:11:58
  Event ID:      11707
  Product: DAQFactory -- Installation completed successfully.
 

I re-registered MSIEXEC incase it was not installed correctly; maybe some Windows7 service is causing the problem.

 

I will try to get my head around the classes idea and modify the code to suit.

[AzeoTech]

Actually it does.  Its either under:

 

HKLM/Software/DAQFactory/Control

 

or

 

HKLM/Software/Wow6432Node/DAQFactory/Control

 

depending on whether you are in the x32 or x64 version of Windows.

[philb1]

Ah apologies you're right, my bad; I just checked and the latest Win7 installation I did is a 64bit version; the registry location has changed as you explained.

 

Thanks.

Phil

[AzeoTech]

No worries.  It caught me out the first few times too.  Its something windows does and has nothing to do with DAQFactory settings.  In fact, internally we didn't change a thing.  Windows automatically remaps the registry requests.

[RodSwan]

Hi,

Is there any change in the status of this problem?

 

I'v been quite happily running 5.90 (2197) on my windows 7 development system for some time now without problem, and I upgraded 6 runtime machines to windows 7 about 2 weeks ago and they have also been working ok.

Today I have replaced all six machines with new PC's, again running Windows 7, and they all now exhibit this problem.

 

I use Registry variable extensively so don't really want to change the code.

 

I've had to temporarily set DF to run in compatibility mode.

 

Does 5.91 help with this problem?
 

 

Rod.

[AzeoTech]

Alas, there is really nothing we can do about this.  What we'll probably do is create a file store registry variables instead of the registry itself.  That would eliminate the authentication problems.  The problem with this workaround is existing OEM apps that rely on registry variables to provide a certain level of copy protection.  As such we'd probably make it as a separate feature.  That all said, you can implement this yourself using a class, and in fact in doing so you eliminate the issues related to registry variables (like being stuck with integers), and you can create more structured storage including arrays.  For example:

class CGlobals
    local firstVar = 0
    local secondVar = 3
    local string thirdStrVar = "defaultValue"

    function save()
        try
           private handle = file.open("c:\daqfactory\settings.json", 0, 1, 0, 1)
           file.write(handle, toJson())
           file.close(handle)
       catch()
           ? strLastError
       endcatch
   endfunction
   
   function load()
        try
           private handle = file.open("c:\daqfactory\settings.json", 1, 0, 0, 1)
           private string datain = file.read(handle)
           file.close(handle)
           fromJson(datain)
        catch()
           ? strLastError
        endcatch   endfunction
endclass

 

Then instantiate the class.  I use simply "g" for my global settings:

 

global g = new(CGlobals)

g.load()

 

Then to use the variables, just put g. in front:

 

g.firstVar

 

And finally whenever you want to save, do:

 

g.save()

 

Unlike registry variables you have to save explicitly.  

 

I've attached a sample with pretty much this exact code.  It'll complain about the file not being found the first time you run.  Then just go to the command alert and change one of the variables and save:

 

g.firstVar = 10

 

g.save()

 

Then restart DAQFactory and load the doc.  If you do: 

 

? g.firstVar 

 

you'll see it holds the 10.

 

 

 

[JohnyQuick]

I had to revisit this problem about my document not writing to the windows 7 registry.  It was working fine on the machine that initially had ver 5.87 a, then updated to 5.9 something to use the SSL email out.

 

Well, Hackers invaded my old machine again, and showed their pointy ears, so I reinstalled all my stuff to the 5.90 version, because it has my most advanced documents, but, bam,  not writing to the registry.

 

I used your advice and reinstalled 5.90 with UAC turned OFF. My document was kopasetic, and wrote to the windows 7 registry.

 

Great!.  Then I turned UAC back on to the default setting, and great. My document still writes to the Win 7 registry with UAC back on.

 

Just wanted to share that. Daqfactory has amazing support-right here on the forum, if you look for it.

 

I want to transfer everything back to 5.87, for password reasons, but it would take some work for such little added protection, and I wouldnt get the SSL email out, which is working fine.

 

Which brings to a question. Does SSL email work coming into DF? or just going out? and if not, is that something you are working on, and if not-why not?

 

As usual DF rocks! and keep up the good work!

[AzeoTech]

SSL works only on outgoing at present.  We just haven't enabled it on the incoming, partially because no one asked for it and we didn't think many people actually used incoming POP3.  If its something you'd like to see happen, please post a request on the Feature Requests forum.