Can't compile after latest GFA upgrade... Windows 10 64

[dragonjim]

Hi,

Which version of GFA did you upgrade to? Did you upgrade the IDE (gfawin32.exe) or just the OCX (gfawin23.ocx)? If I remember correctly, the compiler is called from the IDE so this should be where your problem stems from.

I have successfully compiled your short code on IDE v2.40 - is this the version you are using?

Have you tried creating a new instance of the GFABASIC/Bin folder and running GFA from there?

Sorry - lots of questions and not many answers, except that I have not had such a drastic failure of the compiler with the new upgrade.

[dragonjim]

Hi,

Well you've got the latest version of the IDE (2.40) which should work OK.

Close all open occurrences of GFABASIC, open regedit.exe, find the GFA key (Computer\HKEY_CURRENT_USER\Software\GFA) and delete it. The try compiling again. (This shouldn't work but ...)

If that doesn't work then it might be best to download the gb32.zip file from the repository, delete your current installation (clearing the registry as above) and create a new one.

There are problems with the compiler that Sjouke is currently working on (mainly with regard to the compilation of large libraries) but these are related to memory release errors before a second or consecutive compile action, not on the first attempt which, barring syntax errors, has always seemed to work OK.

[dragonjim]

Hi,

Sorry, I should have been more explicit: download g32.zip from the link on this page.

If that does not work, here is version 2.30 of the IDE: GfaWin32-2.3.zip (472.93 KB) . Rename your current GfaWin32.exe file to GfaWin32-old.exe and then extract the older version from this link and use it instead.  See if this compiles the code.  If so, the problem most likely exists in the more up to date version of the IDE; if not, then the problem lies in your set up somewhere - in that case, if you're on Win7, try running sfc /scannow from the Command Prompt (in Administrator mode) and see if there are any problems with the system files (I suggest this as I once had a major problem with 32-bit programs running on 64-bit Windows - admittedly in Windows 10 - and I eventually tracked the problem down to a corrupt system file).

If you find the problem lies with the newer version of the IDE, then this should be a short-lived problem as I am assured by Sjouke that he is working on a newer version that explicitly deals with known compiling issues and he intends to release it sometime early next year.

I hope some of this is helpful...

[dragonjim]

Hi,

Interesting that the fault seems to lie in the .gll file... I have no answer at the moment but will get back to you when I do.

In the meantime, have a Merry Christmas.

[factor23]

Hello,

I have the same problem with windows 10 64

Bonne année / Happy new year

Jean-Jacques

[dragonjim]

Hi,

Just a quick update. Apparently, there is a known bug related to the dialog routine used in the compile process within the GLL which (also apparently) relates to a missing Try...Catch loop and thus any error thrown causes a fatal crash (although I get the feeling that this is a rather simplified explanation).

Suggestions for the meantime: un-Zip the GB32 files to My Documents rather than My Programs(x86) and see if this makes a difference.

Bonne année / Happy new year

[infoliner]

Ok I would like to continue the work with GB32, I installed all the newest files from Sjouke and I have the same problem,
on 2 different computers with Win7/64 and Win10. Nothing can be compiled, even when Initializing the name or adding an icon,
GB crashes. I would like to hear, what else You tried and what Sjouke has to say about that and a way to circumvent the problem,
until there is a solution.

ThankYou all

Christian

[dragonjim]

Hi.
Have you tried using version 2.30 of the IDE - see my post for 20th Dec?

I can confirm that I installed GFABasic from Sjouke's site, substituted v2.30 for v2.40, and compiling worked as usual. This is on both Win10 32-bit and Win10 64-bit.

[dragonjim]

Hi.

A quick update for all interested parties:

A fix has been written for GfaWin32.gll and is in the testing process. As it is one of a number of fixes and new features, the testing will take some time but it is hoped that a stable version will be ready for release sometime next week.

In the meantime, removing the GfaWin32.gll file from Extra -> Extension Manager should serve as a temporary fix (as reported by JMM above) but be prepared that this will also remove other familiar IDE features added through the extension file.

[dragonjim]

Hi,

Good news! An update has been released that fixes this problem, as well as a number of other problems. Binaries can be downloaded by clicking the link on this page.

If anyone has any further problems with this, please post the details on this thread.

[dragonjim]

Hi,

There are some know issues with Ocx controls in the new IDE version 2.42. I shall add these to the list, pass them on and let you know when they are fixed.

In the meantime, please try GfaWin32.exe version 2.30 (see my post of 20th December) to see if these problems occur with that also (it will give an idea whether the problem lies in the IDE or the .gll). I know the problems reported so far do NOT occur with v2.30, which works perfectly well with the new .gll file.

[dragonjim]

Hello once again.

It appears that the problem may not be with the GFABasic IDE but the way Windows handles the manifest file (see here). The problems you reported may well be caused by this inconsistency - problems involving ComboBox drop down lists not working and the like have certainly been caused by it.

A quick way of testing this may be to rename the GfaWin32.exe file (to, say GfaWin32-old.exe) and back again - there are other examples in the article referenced by the link above.

Please let me know if this does or does not help.

[dragonjim]

Hi again,

Quick question for JMM: When was the last time you were able to change the ForeColor of a Frame?

I only ask as I tried to find out where things 'broke' by using IDE versions 2.30 and 2.42 and OCX builds 1171 (2012), 1185 (2013), 1200 (Mar 2017) and 1202 (Sep 2017) and I could not effect the change of ForeColor of a Frame on my Win10/32 and Win10/64 machines using the IDE (as you described). So I dug out my 2006(?) laptop that still runs XP and on which I installed GFABASIC in early 2012 and have never updated it and I could not change the ForeColor on that either. Hence it looks like the IDE has been broken for ever...

Interestingly enough, however, when I compiled the program in each case, I was able to change ForeColor as I had intended, even with IDE v 2.30 and OCX build 1202. I will check again with Sjouke but he said he did not have the problem the last time I asked.

Quick question for everyone else: Is anyone else experiencing the same problem as JMM. To make testing easier, use the code below:

Form frm1 = "", 10, 10, 400, 400
Ocx Frame fr1 = "frame 1", 10, 10, 200, 200
Local c As Control
For Each c In frm1.Controls
If TypeOf(c) Is Frame Then c.forecolor = RGB(255, 0, 0) // With new version the text remains black.
If TypeOf(c) Is Frame Then c.backcolor = RGB(255, 255, 255) // With new version the background turns white.
Next
Do : Sleep : Until frm1 Is Nothing

[dragonjim]

A further update to the above:

All those combinations of IDEs and OCXs work as expected once the program is compiled ONLY if the side-by-side manifest file is not present (but it does work if added as a resource through IDE v2.42 or other means). If there is one, then ForeColor is not changed, even in the compiled version.

Does anyone else find this?

Maybe the answer to your problem is here is Sjouke's blog: Update doesn't load manifest file. If so, please leave a comment on his blog as well as this forum.

[dragonjim]

Hi,

Thanks for the feedback. Just one question: after "un-selecting 'Add manifest resource' in the 'Create Exe' dialog", did you run the executable with a standalone manifest? If not, then the reason it worked is that the created executable was not using Common Controls version 6 - once called XP styles - which the manifest (whether added internally or as a standalone) attempts to ensure, and which GfaWin32.exe.manifest facilitates within the IDE/Editor.

It will be interesting to see what you find on a different machine.

[dragonjim]

So it looks like embedded manifest files do not work with your compiled applications - sadly, I can not reproduce that on my systems (even my old WinXP laptop) but I do not have Win7 so I wonder if the problem may lie there.

Sjouke has extended his blog post here and some of the information/suggestions may be of interest to you.

In the meantime, you can also try out GfaWin32.exe v2.30 to see if you still experience the same problems with the older IDE.

[dragonjim]

That's good to hear. So what are the remaining issues that you have with the new release? Incorrect animation?

[dragonjim]

Hi,

Before trying to provide an answer to your questions, I think the following background information may be useful:

1. The 'Add Manifest Resource' simply replicates the old method of adding a standalone manifest file for each compiled project (if you wished to use Common Controls v6 rather than v5). The old method used to involve copying the gfawin32.exe.manifest file and then renaming it to coincide with the compiled program (e.g. if a compiled program was named 'My program.exe', then the accompanying standalone manifest would have to be renamed 'My program.exe.manifest') - the new 'Add Manifest Resource' option just saves having do all that and gets round one or two unusual bugs such as some manifest files which included spaces not being recognised (e.g. in the example above, you would need to either remove all spaces or replace them with an underscore ('_')).

2. Common Controls v6 are stricter and less flexible than v5: for example, Button Forecolor can not be changed from the default (whether it be a command button, check or option box - or, as you discovered, the label of a frame). I don't use animations myself, but I would assume that this is also the reason why your animations are not working as expected. To see what I mean, compile the following code twice - once with 'Add Manfest Resource' selected and once without - and you will notice the difference.

OpenW 1
Ocx Frame frm = "Frame", 10, 10, 200, 200 : frm.ForeColor = 255
Ocx Command cmd = "Command", 20, 30, 100, 25 : cmd.ForeColor = 255
Ocx Option opt = "Option", 20, 60, 100, 17 : opt.ForeColor = 255
Ocx CheckBox chk = "Checkbox", 20, 82, 100, 17 : chk.ForeColor = 255
Do : Sleep : Until Win_1 Is Nothing

3. The IDE for GFABASIC-32 has a standalone manifest file, which means that all it's internal controls - and all those included in a program run inside the IDE - use Common Controls v6.

I am guessing that, prior to using the latest version of the IDE (v2.42), you did not create a standalone manifest file for your compiled executables: hence, you designed the program in the IDE (under Common Controls v6) where things did not work quite as expected, but this didn't matter as, once compiled with no accompanying manifest file, the program ran using Common Controls v5 and all controls behaved as you wished.

However, in the newest version, by selecting 'Add Manifest Resource', you are forcing your compiled programs to run using Common Controls v6 and are thus replicating the behaviour you found when running the program within the IDE; by unselecting it, you are returning to what you did previously and running your compiled programs under Common Controls v5.

My suggestion would be to rename the manifest file in your Bin folder (gfawin32.exe.manifest) and see if the behaviour changes within the IDE to that which you expect to see in the compiled program.

I hope some of that is helpful.

[dragonjim]

Hi,

I'm glad that helped.

From what I understand, Common Controls v5 is a generic cross-OS standard which anyone who used Windows 95/98/ME will be familiar with, and is retained for backwards compatibility - and, possibly, to allow the sort of customisation that you like. Basically, they appear the same regardless of which version of Windows you are using.

On the other hand, Common Controls v6 - originally called XP-Styles - is OS-dependent and change according to which version of Windows you are using, to conform to the styling of that particular OS.

Hence, you could see v6 as not really a successor but an alternative to v5: if you want your controls to be reproduced faithfully whatever version of Windows they are run on, use v5; however, if you want them to adapt to the style of the parent OS, use v6 - with all its limitations.