MyFbFramework - My FreeBasic Framework

[Xusinboy Bekchanov]

Yes a change previously made in the compiler but for now pending, already fixes the issue with gas64.

Thank you.

[coderJeff]

Checks for some symbol that is not local?

Yes, the internal asserts in fbc are sanity checks to ensure that fbc's code is handling a known scenario - the asserts are omitted in release versions. If an fbc assert fails it indicates that there may be a new bug to contend with or that changes to fbc now allow fbc to handle new scenarios correctly. I will try to assess. Thank-you.

EDIT:
These lines should cause fbc to throw an error, but does not:
https://github.com/XusinboyBekchanov/Vi ... 7-L3416C27

Statements are not allowed in the body of a namespace and should be giving an error.

EDIT:
https://sourceforge.net/p/fbc/bugs/995/

[Xusinboy Bekchanov]

EDIT:
These lines should cause fbc to throw an error, but does not:
https://github.com/XusinboyBekchanov/Vi ... 7-L3416C27

Statements are not allowed in the body of a namespace and should be giving an error.

EDIT:
https://sourceforge.net/p/fbc/bugs/995/

But it works without any problems.

[coderJeff]

But it works without any problems.

Maybe it works for you but there is other problems under the surface like dealing with temporary variables and temporary instances of objects that fbc won't handle well.

The intent of namespaces is that access to its contents is well controlled and contents are contained within the namespace without spilling out in to other contexts. Direct statements in a namespace block is not the intended design of namespaces.

If allowed as-is, statements from the namespace block will be executed in either the context of the implicit main or intializing module constructor (depending on how and where the code was compiled), essentially seeing code from inside a namespace as module level code.

So, to execute code from a namespace in the implicit main or module constructor it should be a requirement to write the statements outside of the namespace - therefore at module level - or to explicitly indicate that should be part of the module initialization.

For example, for your code in Designer.bas, should be required to do 1 of 2 things:

Put the statements outside of the namespace to indicate they are module level (and as a consequence will have access to local module level variables):

Code: Select all

    ...
end namespace

My.Sys.Forms.mnuDesigner( ML( ....

Or put the statements inside a module constructor procedure:

Code: Select all

namespace My.Sys.Forms
  sub mnuDesigner_init constructor
    My.Sys.Forms.mnuDesigner( ML( ....
  end sub
end namespace

[Xusinboy Bekchanov]

Maybe it works for you but there is other problems under the surface like dealing with temporary variables and temporary instances of objects that fbc won't handle well.

The intent of namespaces is that access to its contents is well controlled and contents are contained within the namespace without spilling out in to other contexts. Direct statements in a namespace block is not the intended design of namespaces.

If allowed as-is, statements from the namespace block will be executed in either the context of the implicit main or intializing module constructor (depending on how and where the code was compiled), essentially seeing code from inside a namespace as module level code.

So, to execute code from a namespace in the implicit main or module constructor it should be a requirement to write the statements outside of the namespace - therefore at module level - or to explicitly indicate that should be part of the module initialization.

For example, for your code in Designer.bas, should be required to do 1 of 2 things:

Put the statements outside of the namespace to indicate they are module level (and as a consequence will have access to local module level variables):

Code: Select all

    ...
end namespace

My.Sys.Forms.mnuDesigner( ML( ....

Or put the statements inside a module constructor procedure:

Code: Select all

namespace My.Sys.Forms
  sub mnuDesigner_init constructor
    My.Sys.Forms.mnuDesigner( ML( ....
  end sub
end namespace

Thanks for the explanation, I've moved it:
https://github.com/XusinboyBekchanov/Vi ... 9d8010343c

[PeterHu]

Please let us know which version is more stable after you fixed the issue.Thank you so much.

Ok.

Just let you know It is ok now with the fresh rebuilt with most updated MyFbFrameWork of today.Maybe it is not related to mff,but this time it just works.

[Xusinboy Bekchanov]

Please let us know which version is more stable after you fixed the issue.Thank you so much.

Ok.

Just let you know It is ok now with the fresh rebuilt with most updated MyFbFrameWork of today.Maybe it is not related to mff,but this time it just works.

Thanks for reporting this, I think it's due to the version of ld.exe, as I said before.