Hi,
I just installed FF3.0.8 on a fresh (a week old) Windows 7 64-bits computer and allthough no "complains" from FF it seams when setting compiler and similar settings, as well as "Resent project" listing doesn't take. Each time I start FF I'm presented with a dialog to set compiler and such, then selecting project has not registered earlier opened projects, nor is settings for these projects saved.
Changes in code does take though. Anybody else using FF 3.0.8 in W7-64 or have any insight? I imaging right clicking FireFly3.exe for Properties and on "Compatibility" tab set Prevelege level "Run this program as an administrator" may fix it or cause trouble? I haven't done that yet as I wanted to hear what others may have to say first.
/Joakim
I am not sure whether this may be the cause. I guess it may be.
For many years, Microsoft have been encouraging developers to put program writable files in the AppData or the MyDocuments folders. From Vista onwards, they implmented the OS to be very fussy on this.
I would encourage that when installing FF3 to select:
"Install to the user's "My Documents" folder" (see screen shot)
for the "Location to install the CodeStore, Function Library, Settings and Projects"
Of course I'm too restless to sit around waiting... ??? and yes selecting "Run as Administrator" does solve it. I hope it will help someone running into the same situation.
I think this may have to do with an option during installation were I have a vague memory it mentioned something about having write premissions or similar.
And was just noticed of your reply Cho (thanks), yes that was the option I refrained from "Install to the user's 'My Documents' folder" because I think that's the correct place to put data or settings, but not to install a program. I understand Paul probably wants to keep all at one place but I have to say long gone are the days of simplicity when everything could be placed at one location.
I like to install my programs in "program Files" and then files that need to be writable either to My Documents or User's AppData were you also can decide if you want to use the Shared or user specific space. I haven't checked really were FF keep its settings.
/Joakim
If the option is chosen, FF3 program will still be installed to the protected (in Vista and W7) Program Files folder. Only CodeStore, Function Library, Settings and Projects (which will be written to in the course of normal use) are installed to the My Documents folder.
Otherwise, everything will be installed to the protected Program Files folder.
I had this problem with some programs under Vista too. That's why I put my programs usually in the folder C:\rbsoft.
If you install FF3 into C:\FF3 or something similar the problem disappears.
If you don't want to install something under C:\Program Files because that's a protected system area (and some programs don't deal with that too well), rather than just installing at the drive root (e.g.: C:\), I'd suggest installing under C:\Users\Public. For example, I use C:\Users\Public\Programs and that's where I installed some tools like Eclipse. That's a location where any program is guaranteed to have full access to all files and can freely create files in its own installation folder (now, and in future releases of Windows)
Installing programs in the C:\Users\... location is discouraged for security reason, although there is nothing to stop anyone from doing so.
In fact, the entire C:\Users\... directory structure is intended by Microsoft to be off limit to program executables. Config, settings, project files, files that will be edited/changed are allowed.
Also, do note that C:\Users\Public\ is available to ALL users on the computer, if it is shared and there is more than one user.
Quote from: Cho Sing Kum on June 11, 2010, 09:10:30 AM
If the option is chosen, FF3 program will still be installed to the protected (in Vista and W7) Program Files folder. Only CodeStore, Function Library, Settings and Projects (which will be written to in the course of normal use) are installed to the My Documents folder.
Otherwise, everything will be installed to the protected Program Files folder.
Ahh I understood it as if the program would install there, that's another ball game then. But now that seem to work and I don't have any problem with running is as admin.
I have another PB/FF Win7 related problem though which also involves VB6, where a dll created in FF refuses to load when used in a VB6 program and running it in the IDE while used in a compiled VB6 app it loads fine. But that's yet another ball game!
I have the same problem when I use VB6 and SQLitening under XPPro.
IIRC, when I was testing Cheetah Database in VB6, it would load and work the first time but it would fail on subsequent "compiles". At the time, I think it was related to the VB environment itself keeping the DLL in memory and not unloading it (FreeLibrary). Actually, I create a specific Cheetah function that the user could call to ensure that the Cheetah DLL would get unloaded. This would allow you to be able to continue testing from within the VB environment rather than having to do the compile to exe option all the time.
Quote from: Cho Sing Kum on June 11, 2010, 02:07:11 PM
Installing programs in the C:\Users\... location is discouraged for security reason, although there is nothing to stop anyone from doing so.
In fact, the entire C:\Users\... directory structure is intended by Microsoft to be off limit to program executables. Config, settings, project files, files that will be edited/changed are allowed.
Also, do note that C:\Users\Public\ is available to ALL users on the computer, if it is shared and there is more than one user.
Sure, that's the point. I wasn't saying that people should be doing that by default, I specifically mentioned it as an
alternative to installing software in the root directory. Older software that doesn't "play well with others" expects that it has full run of the system and is able to access everything, which is exactly what it's able to do under C:\Users\Public. And yes, it violates best practices and can present security issues, but if you're the sole user on that machine and you have to use that code, it's a better option that installing it off of root, IMO.
Joakim,
I use a little Freeware addon - vbAdvance - that makes things a little easier when dealing with Dlls.
You can download it here:
http://vb.mvps.org/tools/vbAdvance/
Quote from: TechSupport on June 11, 2010, 03:06:05 PM
IIRC, when I was testing Cheetah Database in VB6, it would load and work the first time but it would fail on subsequent "compiles". At the time, I think it was related to the VB environment itself keeping the DLL in memory and not unloading it (FreeLibrary). Actually, I create a specific Cheetah function that the user could call to ensure that the Cheetah DLL would get unloaded. This would allow you to be able to continue testing from within the VB environment rather than having to do the compile to exe option all the time.
I think this is a specific VB6/Win7 problem, so probably OT here :'( but it was all fine before in XP Pro, not until I switched over to Win7 a week ago and tried to start the program in VB6 IDE this dll burked out with an error 53 "dllname.dll" Not found. I have tried to put it both in the Exe dir, System32 and SysWOW64 w/o success. Interesting though, another dll created with FF loads fine and the exports for the called function is practically identical, just different names.
I suspect it has to do with this call in the dll
hModule = GetModuleHandle("dllname.dll")(Yes it asks for a handle to it self)
which is later used in
Function GetString(lngStringID As Long) As String
Local nChars As Long
Dim szString As Asciiz * 4096
nChars = LoadString(hModule, lngLangOffset + lngStringID, szString, SizeOf(szString))
Function = szString
End Function
to load strings from the resource file backed into the project. I don't know if it's the best way but it's the only way I been able to read the resource strings, but now the dll doesn't load anylonger in VB6 IDE running in Win7.
Quote from: Rolf Brandt on June 11, 2010, 03:46:12 PM
Joakim,
I use a little Freeware addon - vbAdvance - that makes things a little easier when dealing with Dlls.
You can download it here:
http://vb.mvps.org/tools/vbAdvance/
Thanks Rolf, I will investigate it but a brief look just tells me it can be useful. Good to see as well I'm not the only "VB6 junkie" here 8)
I use i mainly because of the Build and Execute button in the IDE, but it has some really powerfull functions. I use VB6 still for my older apps and for Mappoint related software.
All my newer app I am doing now in PB/FF3.
Joakim, seems that the download link vor vbAdvance does not work. If you experience the same problem let me know. I can upload the install file for you.
Quote from: Rolf Brandt on June 12, 2010, 04:24:47 AM
Joakim, seems that the download link vor vbAdvance does not work. If you experience the same problem let me know. I can upload the install file for you.
Yes you are right, been enjoying the sunshine but notice now it wont download. I would be grateful to receive it from you, do you have anywere you can upload it?
/Joakim
Here is the link:
http://download.rbsoft.eu/vbadvance.rar (http://download.rbsoft.eu/vbadvance.rar)
Thanks Rolf,
I downloaded it too.
Looks like all the subdomians of mvps.org are not working at this time.
Too bad, it was always a good source.
Thanks! Got it too.
/Joakim
Joakim Schramm,
I had the same problem that you mentioned in the earlier part of this thread.
The solution, for me at least, is to start FireFly in Administrator Mode... also, the test program that I was trying to compile, now compiles and runs, since the PBRES.exe was not loading either.
Thanks,
Buck