Type: required
Title: ResMgr fallback mechanism will be discontinued
Posted by: [EMAIL PROTECTED]
Affected: all using ResId
Effective from: CWS resicleanup
*Summary*
--------
-ResId( <x>, ResMgr* pMgr = NULL );
+ResId( <x>, ResMgr& );
-Resource::SetResManager
-Resource::GetResManager
*Description*
-------------
Currently Resources can fall back to the last ResMgr used by not
specifying from which ResMgr they want to be loaded. While this allows
the nice well known construct
MyDialog() :
Dialog( ResId( MY_DIALOG_RESOURCE_ID, GetMyResMgr() ),
myFirstControl( this, ResId( MY_DIALOG_FIRST_LOCAL_ID ) ),
mySecondControl( this, ResId( MY_DIALOG_SECOND_LOCAL_ID ) )
it unfortunately also allows to fall back to a rather undefined ResMgr
that was in use at some point before. Especially in a multithreaded
environment this kind of implicit global state is an absolute nono
since it cannot work reliably.
So after integration of CWS residcleanup, ResId objects will no longer
be allowed to be created without a valid ResMgr. Please note that this
does not remove the state of the ResMgr itself, so access to a ResMgr
still has to be guarded if you want to access local resources in a
resource file. This howerver is currently implicitly done by the
SolarMutex which must be locked when creating vcl windows anyway.
Most modules already have an own ResId object that creates a single
ResMgr on demand specifying their resource. So you could replace the
above by
MyDialog() :
Dialog( MyModResId( MY_DIALOG_RESOURCE_ID ),
myFirstControl( this, MyModResId( MY_DIALOG_FIRST_LOCAL_ID ) ),
mySecondControl( this, MyModResId( MY_DIALOG_SECOND_LOCAL_ID ) )
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
