installation and runtime (memory crash) issues with bridge

in my limited experience with the activeXBridge i have encountered two issues and i would like to know how others have worked around them.

1) the right runtime for my machine. i have nt4 workstation sp6a with ms visual studio c++ (if any of this helps i dunno). i could NOT make the bridge work with runtimes 1.2 or 1.3.0_01 even though the packager tool ran fine and i checked the regedit file. it was doing one thing wrong but even though i fixed it still didn't work. in my desperation i installed 1.3.1 runtime international version. now it works. does anybody know why. or better is there a list of what run-time works on which version of which platform.

2) office apps crash on exit bug. when i first made my test bean and called it from word or excel when i tried to close word or excel. boom! memory exception every time. the problem mysteriously went away when i added some swing components (JOptionPane) to my bean. it doesn't matter whether the components ever get called or not. i have no idea why this works but the memory crash never happens any more

well anyway if anyone has any useful info about (1) or can explain or comment further about (2) i'd certainly appreciate it. this technology is really saving me a lot of vb and/or vc++ headaches....

[1299 byte] By [schleute] at [2007-9-26 3:13:43]
# 1

Also I would like to add a suggestion to those of your having problems with vba and the bridge. Make sure you say (assuming obj is some sort of Java Object accessed through the bridge and previuosly initialized)

Set obj = Nothing

This seems obvious but it does help. Also make sure this code and any other clean up code is being called. This code should always appear in sub AutoClose to make sure.

hrpmrl at 2007-6-29 11:23:17 > top of Java-index,Desktop,Deploying...
# 2

I can confirm the issue with the international installation of the Virtual Machine.

However, I have no idea, what the reason is, it may be some windows problem.

The memory violation at the very end is also a known problem. Apparently, a

native reference is not properly released by the bridge code. Sun promised to

have it fixed for 1.4.

Doing

set obj = Nothing

makes sure that VB releases the VB-reference to the Java object. This has consequences

for the garbage collector and for memory clean-up.

hrpmrl at 2007-6-29 11:23:17 > top of Java-index,Desktop,Deploying...
# 3

I must echo scsi-boy's advice about making all beans descend from Swing components. I've been mucking around in my spare time for a couple of months trying to get some Java beans working in Visual Basic. One of them, a critical RMI linking bean was non-visual, and I suffered frequent crashes of Visual Basic 6. Today I switched that bean to descend from ImageIcon, and suddenly things are alot more stable. Things are still fairly flakey, but my little application occasionally works now.

scsi-boy also mentioned setting references to Nothing, but I wasn't able to do this in the Visual Basic 6 application, at least not in the Form's Load and Unload methods where I have some initialisation and shut down code. I'm not creating my beans dynamically, but am drawing them directly onto the form from the component bar. Could anyone suggest how/where to dispose of them properly, if Visual Basic is not doing the job properly.

Thanks for any further helpful suggestions

hrpmrl at 2007-6-29 11:23:17 > top of Java-index,Desktop,Deploying...
# 4
> Sun promised to have it fixed for 1.4.Does this mean that the Bridge is not dead, as some earlier reports suggested. I'd really like to know before I plough more effort into debugging furtherRegardsMatthew
wright15 at 2007-6-29 11:23:17 > top of Java-index,Desktop,Deploying...
# 5

> scsi-boy also mentioned setting references to Nothing,

> but I wasn't able to do this in the Visual Basic 6

> application, at least not in the Form's Load and

> Unload methods where I have some initialisation and

> shut down code. I'm not creating my beans dynamically,

> but am drawing them directly onto the form from the

> component bar. Could anyone suggest how/where to

> dispose of them properly, if Visual Basic is not doing

> the job properly.

>

> Thanks for any further helpful suggestions

according to my resident vb guru...

VB allows starting with Form or Sub Main(). The second is prone to strange behaviour and is untrustworthy. There is also a console mode that works better for non-visual apps. I have an example of this console mode if you need it.

If you have a form then Load/Unload works. I explicitly create and destroy objects through the ActiveXBridge and it seems to work reliably.

Mabye you can solve your problem by using the standard Form model of VB app and hiding the forms from the user. Visible = False etc.

Overall in Windows in my experience it is better to go with the normal/Form mode which makes things work more consistently.

....

hope you find this helpful. if not i suggest mailto:mrbill@microsoft.com ;)

wright15 at 2007-6-29 11:23:17 > top of Java-index,Desktop,Deploying...
# 6

Thanks - I'll try the dynamic creation approach and see if it helps stability. There are about 10 beans involved, and I'm not sure if I've sorted out all the threading and serialization issues yet, so the remaining problems may well be on my side.

It would be interesting to know why beans descended from Swing Components work more reliably. My non-visual bean was already Serializable, which was one explanation offered in the past.

Regards

Matthew

wright15 at 2007-6-29 11:23:17 > top of Java-index,Desktop,Deploying...
# 7

I am now suffering from a out of memory error.....

I'm closing all my objects correclty, I'm zipping & encrypting input files using

a Java Class wrapper for the Entrust Desktop Security software......

Is it possible to allocate more space to the JVM?

Regards

Nick

wright15 at 2007-7-1 3:31:56 > top of Java-index,Desktop,Deploying...
# 8

>

> I am now suffering from a out of memory error.....

>

> I'm closing all my objects correclty, I'm zipping &

> encrypting input files using

>

> a Java Class wrapper for the Entrust Desktop Security

> software......

>

> Is it possible to allocate more space to the JVM?

>

i believe the answer to this question is unfortunately no. you can do it otherwise but not using the bridge, at least no one has done it successfully to my knowledge.

this is a link to previous post on this subject (more or less) http://forum.java.sun.com/thread.jsp?forum=40&thread=245066

after reading this i mucked about with the reg stuff and such to see if there was anything i could configure to do this and i could not find anything.

at this time i believe the jvm is started in the ocx and it is hard-coded as to the startup. only the path and such are dynamic.

none of this of course helps you...

i would suggest finding out where your code is breaking with the error and seeing if there is some alterntive way to fix it... probably there is. one somewhat wild guess based on what you have said is to buffer the parts of the file yourself... that is read, process and write the file(s) in chunks.

Guest at 2007-7-1 3:31:56 > top of Java-index,Desktop,Deploying...
# 9
Hi Scsiboy,Does the JVMControl not offer any options...?Nick
wright15 at 2007-7-1 3:31:56 > top of Java-index,Desktop,Deploying...
# 10

Hi Scsiboy,

The JVMControl does appear to have solved my problem...

Dim objJVM As JvmControl

Set objJVM = New JvmControl

objJVM.AddOption ("-Xms32m")

objJVM.AddOption ("-Xmx32m")

objJVM.StartJVM

' Calling the Java Classes....

set objJVM = nothing

This is setting my JVM's initial memory allocation to 32mg and

has therefore solved my problem...

Nick

wright15 at 2007-7-1 3:31:56 > top of Java-index,Desktop,Deploying...