Hi Thomas,
your executable calls - just like the original ExtApp does -
berry::Starter::Run(...), right? This code lives in
liborg_blueberry_osgi.dll, hence your executable has a link time
dependency on it. This is why this plugin is special. Even before the
CTK migration, BlueBerry applicatio
On 19.10.2011 22:39, Sascha Zelzer wrote:
> Hi,
>
> your application loads liborg_blueberry_osgi.dll twice. The first time,
> the Windows library loader loads it from "bin/" due to the linker
> dependency of your executable to it. This initializes the
> berry::InternalPlatform singleton and a Poco
Hi,
your application loads liborg_blueberry_osgi.dll twice. The first time,
the Windows library loader loads it from "bin/" due to the linker
dependency of your executable to it. This initializes the
berry::InternalPlatform singleton and a Poco::Util::Application instance
with the static varia
Hi,
On 10/19/2011 11:16 AM, Thomas Wolf wrote:
> My provisioning files are:
>
> main project:
> --->
> READ file:///<{REMOVED}>/vc9_x64/bin/ExtApp.provisioning
>
> START file:///<{REMOVED}>/vc9_x64/bin/libehtz_isosurface.dll
> START file:///<{REMOVED}>/vc9_x64/bin/libethz_automaticsegmentation.dll
Hi,
> i tried the BlueBerry.consoleLog command line argument. Output is:
>
> --->
>
> Wed Oct 19 10:54:16 2011
> 0.20 blueberry.osgi.codecache: Creating CodeCache with path:
> \AppData\Local\ETH Z³rich\Medical Scene Gene
> ration_195299671\bb-plugin_cache\
> 0.22 blueberry.osgi.intPltfm: Plugin ba
Hi,
we have some trouble debugging this...
As far as i understand the code, InternalPlatform::GetInstance() is a
singleton (after Meyers, static).
So it shouldn't be possible that there is another InternalPlatform
instance created for a second time. This happens for the first plugin,
'syste
My provisioning files are:
main project:
--->
READ file:///<{REMOVED}>/vc9_x64/bin/ExtApp.provisioning
START file:///<{REMOVED}>/vc9_x64/bin/libehtz_isosurface.dll
START file:///<{REMOVED}>/vc9_x64/bin/libethz_automaticsegmentation.dll
START file:///<{REMOVED}>/vc9_x64/bin/libethz_basicimageproce
On 18.10.2011 22:53, Sascha Zelzer wrote:
> Hi Thomas,
>
> the code below looks fine. The "plugin cache" is a remnant from the
> legacy BlueBerry Plugin system and it is not needed anymore. Application
> configuration data can be either in code (as below) or using .ini files
> (they have precedence
Hi Thomas,
the code below looks fine. The "plugin cache" is a remnant from the
legacy BlueBerry Plugin system and it is not needed anymore. Application
configuration data can be either in code (as below) or using .ini files
(they have precedence). Not having any .ini files is fine, if all
nece
Addendum:
Apparently its just one of regularly thrown exceptions. The fatal
problem is the folliwing console output:
Assertion violation: _pInstance == 0 [in file
"..\MITK\Utilities\Poco\Util\src\Applicatio
n.cpp", line 122]
On 17.10.2011 16:08, Thomas Wolf wrote:
> Dear all,
>
> while starting our ExtApp project, there seems to be some problems
> reading the startup configs files (now called *.provisioning I think).
>
> I made sure that the files in questions are found indeed, and traced it
> to the config keyword "Bl
Dear all,
while starting our ExtApp project, there seems to be some problems
reading the startup configs files (now called *.provisioning I think).
I made sure that the files in questions are found indeed, and traced it
to the config keyword "BlueBerry.plugin_cache_dir".
this is requested upon
12 matches
Mail list logo
