Anybody using GWTTestCase regularly?
dominik_steiner
I was wondering if anybody is using GWTTestCase regularly. (as there
are not many posts seen on this subject in the forum -> 44 in total
over the last 8 months)
I was having a go at GWTTestCase some time ago, but found it quite
slow and it was a pain to get it up and running.
Now I got back to it and with the help of the junitCreator.cmd created
a BasicTest and got this running. I encountered some problems in the
process:
* TimeoutException: there is just the notice that after 20 s the test
case throws this exception. In the src there's just the comment that:
// Set a timeout period to automatically fail if the servlet
hasn't been
// contacted; something probably went wrong (the module failed
to load?)
It would be great to have a hint why the servlet failed??
* when the code to test consists in some part of js-Libraries the
GWTTestCase fails with
com.google.gwt.core.client.JavaScriptException: JavaScript TypeError
exception: Objekt erwartet
at
com.google.gwt.dev.shell.ie.ModuleSpaceIE6.invokeNative(ModuleSpaceIE6.java:
435)
at
com.google.gwt.dev.shell.ie.ModuleSpaceIE6.invokeNativeHandle(ModuleSpaceIE6.java:
211)
at
com.google.gwt.dev.shell.JavaScriptHost.invokeNativeHandle(JavaScriptHost.java:
93)
at
com.mapitz.gwt.googleMaps.client.GLatLngImpl.create(GLatLngImpl.java:
7)
at com.mapitz.gwt.googleMaps.client.GLatLng.<init>(GLatLng.java:29)
at
com.gwt.client.controller.MapController.addPoint(MapController.java:
83)
at com.gwt.client.Test.testAddPoint(Test.java:31)
at com.gwt.client.__Test_unitTestImpl.doRunTest(transient source for
com.gwt.client.__Test_unitTestImpl:11)
at junit.framework.TestCase.runTest(TestCase.java:64)
at junit.framework.TestCase.runBare(TestCase.java:38)
at
com.google.gwt.junit.client.impl.GWTTestCaseImpl.runTest(GWTTestCaseImpl.java:
295)
at com.google.gwt.junit.client.impl.GWTTestCaseImpl.access
$1(GWTTestCaseImpl.java:289)
at com.google.gwt.junit.client.impl.GWTTestCaseImpl
$JUnitHostListener.onSuccess(GWTTestCaseImpl.java:65)
at com.google.gwt.junit.client.impl.JUnitHost_Proxy
$2.onCompletionImpl(transient source for
com.google.gwt.junit.client.impl.JUnitHost_Proxy:130)
at com.google.gwt.junit.client.impl.JUnitHost_Proxy
$2.onCompletionAndCatch(transient source for
com.google.gwt.junit.client.impl.JUnitHost_Proxy:108)
at com.google.gwt.junit.client.impl.JUnitHost_Proxy
$2.onCompletion(transient source for
com.google.gwt.junit.client.impl.JUnitHost_Proxy:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
com.google.gwt.dev.shell.ie.IDispatchImpl.callMethod(IDispatchImpl.java:
107)
at
com.google.gwt.dev.shell.ie.IDispatchProxy.invoke(IDispatchProxy.java:
140)
at
com.google.gwt.dev.shell.ie.IDispatchImpl.Invoke(IDispatchImpl.java:
274)
at
com.google.gwt.dev.shell.ie.IDispatchImpl.method6(IDispatchImpl.java:
177)
at
org.eclipse.swt.internal.ole.win32.COMObject.callback6(COMObject.java:
117)
at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1925)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2966)
at com.google.gwt.dev.GWTShell.pumpEventLoop(GWTShell.java:657)
at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:337)
at com.google.gwt.junit.JUnitShell.runTest(JUnitShell.java:120)
at com.google.gwt.junit.client.GWTTestCase.runTest(GWTTestCase.java:
177)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at com.google.gwt.junit.client.GWTTestCase.run(GWTTestCase.java:114)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:
128)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:
38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:
460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:
673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:
386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
196)
I interpret this exception that he hasn't found and loaded the js
library. I tried to put a <script> tag into my gwt.xml file, but this
didn't work either.
I'm wondering anyway how the GWTTestCase is working. As we are just
providing the module name which has to be loaded I would guess that
the GWTTestCase is loading this module through it's own html file?
(and not using the one which is provided in the project?)
I would find it very helpful, to have a GWTTestCase which is fast and
better documented. Perhaps I'm not alone with this wish?
Thanks for any contributions you can make to this points.
Cheers,
Dominik
mP
unfortunately is stuck to only using the hosted mode browser which
means its not that great at testing things across multiple browsers.
On Feb 25, 10:49 pm, "dominik_steiner"
dominik_steiner
that's interesting to hear. I only would guess that once you have GWT
specific code in your test code (like GWT.create()) or JSNI methods
there's no way around using GWTTestCase.
Or am I mistaken? What kind of client code are you able to test with
normal JUnit test cases?
Thanks for your reply and I hope that others put their experience here
too...
Dominik
mP
On Feb 26, 4:53 pm, "dominik_steiner" <Dominik.Stei...@partner.bmw-
motorsport.com> wrote:
> Hi mP,
>
> that's interesting to hear. I only would guess that once you have GWT
> specific code in your test code (like GWT.create()) or JSNI methods
> there's no way around using GWTTestCase.
Theres no point to using deferred binding in GWTTestCases because your
test will only ever work against the hosted mode browser :(.
To test against all browsers the easiest thing to do is to write a
normal application and test it once in the hosted mode browser and
then try out other browsers. My wrote something that helps with
executing a junit test as a GWT application meaning you can quite
easily test against all available browsers. It supports stuff like
asking the user to confirm if some visual effect is true and so on.
Check out the rocket.testing.* package.
>
> Or am I mistaken? What kind of client code are you able to test with
> normal JUnit test cases?
I would say that you can easily test non ui components fairly easily.
dominik_steiner
thanks for getting back to me.
> Theres no point to using deferred binding in GWTTestCases because your
> test will only ever work against the hosted mode browser :(.
Ok this sounds reasonable. But what I would like to test is just the
logic and functionality of my app and not test it against different
browser. (well, that would be nice indeed, but I'm just looking for a
quick test feedback which tells me if my method works the way I'm
hoping it should work)
So that's what I like about JUnit tests, the quick feedback they give
you. But if my class has eg a call to GWT.create() (eg in the
constructor in order to create the async services) I would have to
stub those calls, right?
And the second problem is when the code I'm testing is calling JSNI
methods. Do I have to stub those methods out too?
> To test against all browsers the easiest thing to do is to write a
> normal application and test it once in the hosted mode browser and
> then try out other browsers. My wrote something that helps with
> executing a junit test as a GWT application meaning you can quite
> easily test against all available browsers. It supports stuff like
> asking the user to confirm if some visual effect is true and so on.
> Check out the rocket.testing.* package.
>
I had a look into the package you mentioned. Is there some
documentation where I can see how to use it? Can you point me into the
right direction?
Because honestly I didn't understand how the WebPageTestRunner is
supposed to work... it's not extending JUnitTestCase. Do I have to
write my own GWT test module from where I instantiate the
WebPageTestRunner?
> I would say that you can easily test non ui components fairly easily.
And what would you use to test ui components? Or code that has ui
components as a reference?
Thanks again so much for giving me your hints and experience, mP. :-)
I hope that I can find a suitable solution for testing my GWT app. (as
it seems GWTTestCase is not that popular in this forum... :-))
Dominik
Miguel Méndez
The hosted browser is required for testing hosted and web mode testing. However, our JUnit system also allows you to perform remote browser tests. In this configuration, we can launch an external browser (not our hosted browser but things like IE6, Firefox, etc) and have it report back test results to the JUnit launcher just like hosted and web mode. No only that but we also allow you to test asynchronous systems, check out the RPC unit tests in the SVN repo if you are interested in seeing that in action.
Our JUnit support should allow you to test the building blocks of your application as long as they are not UI elements. UI testing is a different matter because you often find yourself wanting to perform screen comparisons and event injection which we do not support.
You might want to submit an issue for the problem that you are running into with the external script. Please include some sample code if appropriate.
Miguel
dominik_steiner
thanks for chiming in. :)
I just submited the issue 737 with source code files attached.
And Miguel, what do you say to the TimeoutException. Is it possible to
get the real error which occured so that the servlet couldn't startup?
And can you explain Miguel, how the GWTTestCase is working behind the
scene.
It is not using my host html file, right? As I'm just specifying the
module name and from that it loads my EntryPoint class and is
therefore running into the onModuleLoad() of my module?
Why is it so slow on startup? Is it doing a full GWT compile? Is there
a way to make the GWTTestCase faster? So that I can have instant
feedback about a method I want to test?
Thanks for any help and information you can give us. :-)
Dominik
On 27 Feb., 12:33, "Miguel Méndez" <mmen...@google.com> wrote:
> I'd thought that I would chime in here to clear up a misunderstanding:
>
> The hosted browser is required for testing hosted and web mode testing.
> However, our JUnit system also allows you to perform remote browser tests.
> In this configuration, we can launch an external browser (not our hosted
> browser but things like IE6, Firefox, etc) and have it report back test
> results to the JUnit launcher just like hosted and web mode. No only that
> but we also allow you to test asynchronous systems, check out the RPC unit
> tests in the SVN repo if you are interested in seeing that in action.
>
> Our JUnit support should allow you to test the building blocks of your
> application as long as they are not UI elements. UI testing is a different
> matter because you often find yourself wanting to perform screen comparisons
> and event injection which we do not support.
>
> You might want to submit an issue for the problem that you are running into
> with the external script. Please include some sample code if appropriate.
>
> On 2/27/07, dominik_steiner <Dominik.Stei...@partner.bmw-motorsport.com>
Miguel Méndez
Comments inline.
Hi Miguel,
thanks for chiming in. :)
I just submited the issue 737 with source code files attached.
And Miguel, what do you say to the TimeoutException. Is it possible to
get the real error which occured so that the servlet couldn't startup?
The client JUnitHost does not know what happened on the server. It only knows that it timed out waiting for the test case to start up. This usually happens if your code fails to compiler or if it takes too long to compile.
And can you explain Miguel, how the GWTTestCase is working behind the
scene.
It is not using my host html file, right?
It synthesizes an HTML file for the test.
As I'm just specifying the
module name and from that it loads my EntryPoint class and is
therefore running into the onModuleLoad() of my module?
Why is it so slow on startup? Is it doing a full GWT compile?
It does do a full GWT compile of the module specified in the GWTTestCase. There have been discussions on the user's group on ways to reduce the amount of classes compiled -- I do not recall the threads right now but they should turn up in a search of the group. Off the cuff, you can create a new GWT module which includes only the classes that you need to test.
--
Miguel
dominik_steiner
thanks for your reply, it cleared up some doubts I had... :-)
See my comments inline
> > And Miguel, what do you say to the TimeoutException. Is it possible to
> > get the real error which occured so that the servlet couldn't startup?
>
> The client JUnitHost does not know what happened on the server. It only
> knows that it timed out waiting for the test case to start up. This usually
> happens if your code fails to compiler or if it takes too long to compile.
>
This sounds much clearer and better to me than TimeoutException. It
would be great to have sth like 'TimeoutException: your code might
have failed to compile or it took too long to compile'. So I could do
a GWTCompile of my app and see what exactly went wrong.
Does this also mean that JUnitHost is always using the internal tomcat
which ships with GWT or can we also tell it to use -noserver?
> And can you explain Miguel, how the GWTTestCase is working behind the
>
> > scene.
> > It is not using my host html file, right?
>
> It synthesizes an HTML file for the test.
>
> As I'm just specifying the
>
> > module name and from that it loads my EntryPoint class and is
> > therefore running into the onModuleLoad() of my module?
> > Why is it so slow on startup? Is it doing a full GWT compile?
>
> It does do a full GWT compile of the module specified in the GWTTestCase.
> There have been discussions on the user's group on ways to reduce the amount
> of classes compiled -- I do not recall the threads right now but they should
> turn up in a search of the group. Off the cuff, you can create a new GWT
> module which includes only the classes that you need to test.
>
This information is very helpful. I haven't been able to find the post
mentioned (at least not specific to GWTTestCase) but as far as I
understand it is to define multiple gwt.xml files in my project and
let my Main.gwt.xml file inherit those gwt.xml files.
So my project structure would look sth like this
/client
/Main.gwt.xml
/client/controller
/client/Controller.gwt.xml
// other packages and gwt.xml files
If i want to just test the classes in the controller package I would
put in my GWTTestCase 'com.foo.client.Controller', which would load
the Controller.gwt.xml file and thus would reduce the amount of
classes which the test would have to compile.
Is this all correct?
Thanks Miguel for your great help. I hope that with this new
information I can soon start to use GWTTestCase more efficiently.
Cheers,
Dominik
> Cheers,
>
> --
> Miguel
Miguel Méndez
Comments inline.
Hi Miguel,
thanks for your reply, it cleared up some doubts I had... :-)
See my comments inline
> > And Miguel, what do you say to the TimeoutException. Is it possible to
> > get the real error which occured so that the servlet couldn't startup?
>
> The client JUnitHost does not know what happened on the server. It only
> knows that it timed out waiting for the test case to start up. This usually
> happens if your code fails to compiler or if it takes too long to compile.
>
This sounds much clearer and better to me than TimeoutException. It
would be great to have sth like 'TimeoutException: your code might
have failed to compile or it took too long to compile'. So I could do
a GWTCompile of my app and see what exactly went wrong.
Good call. Yes, this message should provide hints to help a developer track down the source of the problem. I created issue 745 to track this.
Does this also mean that JUnitHost is always using the internal tomcat
which ships with GWT or can we also tell it to use -noserver?
JUnitHost always uses the internal tomcat instance because it uses a servlet to handle the communication between the test case (running in hosted, web, and remote web modes) and the test runner.
If i want to just test the classes in the controller package I would
put in my GWTTestCase ' com.foo.client.Controller', which would load
the Controller.gwt.xml file and thus would reduce the amount of
classes which the test would have to compile.
Is this all correct?
Yes, you are correct. Note that you may need to update the default values for some of the module file elements since they may not be appropriate relative to the location of your testing module. The following link talks about module files in general:
and this one talks about the different elements of the module file as well as what their default values are:
Thanks Miguel for your great help. I hope that with this new
information I can soon start to use GWTTestCase more efficiently.
Cheers,
--
Miguel
Brill
I use normal JUnit tests that don't require a lot of external support
to run.
- Brill
On Feb 25, 6:49 am, "dominik_steiner"
<Dominik.J.Stei...@googlemail.com> wrote:
> Hi there,
>
> I was wondering if anybody is using GWTTestCase regularly. (as there
> are not many posts seen on this subject in the forum -> 44 in total
> over the last 8 months)
>
> I was having a go at GWTTestCase some time ago, but found it quite
> slow and it was a pain to get it up and running.
[...]
charlie...@gmail.com
true. But abandoning them altogether is a bad idea, IF you use GWT
RPC or a client side model/controller built from GWT. There is simply
no other way to test that stuff.
As much as you can though, you should keep it simple and use regular
JUnit tests (server side model and logic, etc), but for much of a
standard/typical GWT app GWTTestCase and JUnitShell are still needed.
charlie...@gmail.com
even with simple tests, is often caused because your test is not in
the "source-path." Meaning your test is not in the client package or
not defined in the module if in another package.
Even if you use junitCreator, and add NOTHING to the default test, you
can still have this problem, this for example, with an
applicationCreator generated com.Hello module will fail with the
TimeoutException:
$GWT_HOME/junitCreator -junit $JUNIT_HOME/junit-4.1.jar -module
com.Hello com.test.TestHello
Solution, change your test so it is in the client package
(com.client.TestHello) or add the test package to the module source
path.
<source path="client" />
<source path="test" />
On Mar 2, 8:26 pm, "charlie.coll...@gmail.com"
Brill
(although I have run into plenty of very poor code that mad it very
hard).
We have to assume that the GWT code works (otherwise we wouldn't be
using it) so what we're really interested in is testing our own
code... servlets are fairly simple to do that with although you'll
have to use a Mock and/or Fake pattern to do it.
In my case I put all login I can into my own classes and unit test
those, that way there is minimal testing to be done where you have to
include the GWT specific classes.
my 2 cents,
- Brill Pappin
SeanC
> matter because you often find yourself wanting to perform screen comparisons
> and event injection which we do not support.
on the event creation I use the below code to create events in my
unittests, excuse the code in EventUtils as it is a work in progress.
Note: For events to work component has to be added to a page, I just
add to root.
The test below tests that when you click on a SearchTypeLink (one of
my custom components) that css for the component is changed and any
added change listeners are called.
public void testOnClick() {
SearchTypeLink searchTypeLink = new SearchTypeLink("ClickMe",
"ClickTestValue", false);
SearchTypeLinkChangeListener searchTypeLinkChangeListener = new
SearchTypeLinkChangeListener();
searchTypeLink.addChangeListener(searchTypeLinkChangeListener);
RootPanel rootPanel = RootPanel.get(null);
rootPanel.add(searchTypeLink);
EventUtils.sendClickEvent(searchTypeLink);
assertEquals("On Click to Select", "selectedserachlink",
searchTypeLink.getStyleName());
assertTrue("Flag should be set to true if listener called.",
searchTypeLinkChangeListener.onChangeMethodCalled);
rootPanel.remove(searchTypeLink);
}
public class EventUtils {
public static void sendClickEvent(UIObject componentToClick) {
fireClickEvent(componentToClick.getElement());
}
/**
* requires Internet Explorer 5.5 or later.
*/
public static void sendDoubleClickEvent(UIObject
componentToDoubleClick) {
fireDoubleClickEvent(componentToDoubleClick.getElement());
}
/**
* requires Internet Explorer 5.5 or later.
*/
public static void sendMouseOverEvent(UIObject componentToMouseOver)
{
fireMouseOverEvent(componentToMouseOver.getElement());
}
/**
* requires Internet Explorer 5.5 or later.
*/
public static void sendFocusEvent(UIObject componentToFocus) {
fireFocusEvent(componentToFocus.getElement());
}
/**
* requires Internet Explorer 5.5 or later.
*/
public static void sendChangeEvent(UIObject componentChanged) {
fireChangeEvent(componentChanged.getElement());
}
/**
* requires Internet Explorer 5.5 or later.
*/
public static void sendEnterKeyPressEvent(UIObject
componentToKeyPressOn) {
fireEnterKeyPressEvent(componentToKeyPressOn.getElement());
}
static native void fireClickEvent(Element elementToClick) /*-{
elementToClick.click();
}-*/;
static native void fireDoubleClickEvent(Element
elementToDoubleClick) /*-{
var newEvent = $doc.createEventObject();
elementToDoubleClick.fireEvent("ondblclick", newEvent);
}-*/;
static native void fireMouseOverEvent(Element elementToMouseOver) /*-
{
var newEvent = $doc.createEventObject();
elementToMouseOver.fireEvent("onmouseover", newEvent);
}-*/;
static native void fireFocusEvent(Element elementToFocus) /*-{
var newEvent = $doc.createEventObject();
elementToFocus.fireEvent("onfocus", newEvent);
}-*/;
static native void fireChangeEvent(Element elementChanged) /*-{
var newEvent = $doc.createEventObject();
elementChanged.fireEvent("onchange", newEvent);
}-*/;
static native void fireEnterKeyPressEvent(Element
elementToKeyPressOn) /*-{
var newEvent = $doc.createEventObject();
newEvent.keyCode = 13;
elementToKeyPressOn.fireEvent("onkeypress", newEvent);
}-*/;
}
On Feb 27, 11:33 am, "Miguel Méndez" <mmen...@google.com> wrote:
> I'd thought that I would chime in here to clear up a misunderstanding:
>
> The hosted browser is required for testing hosted and web mode testing.
> However, our JUnit system also allows you to perform remote browser tests.
> In this configuration, we can launch an external browser (not our hosted
> browser but things like IE6, Firefox, etc) and have it report back test
> results to the JUnit launcher just like hosted and web mode. No only that
> but we also allow you to test asynchronous systems, check out the RPC unit
> tests in the SVN repo if you are interested in seeing that in action.
>
> Our JUnit support should allow you to test the building blocks of your
> application as long as they are not UI elements. UI testing is a different
> matter because you often find yourself wanting to perform screen comparisons
> and event injection which we do not support.
>
> You might want to submit an issue for the problem that you are running into
> with the external script. Please include some sample code if appropriate.
>
> On 2/27/07, dominik_steiner <Dominik.Stei...@partner.bmw-motorsport.com>
> Miguel- Hide quoted text -
>
> - Show quoted text -
dominik_steiner
wow, impressive responses... so it seems that someone is using
GWTTestCase, it's good to hear that I'm not alone. Thanks for all your
replys.
@ Miguel: I'll keep you updated on what progress and feedback I make
@ Charlie: using GWTTestCase for GWT client app is necessary, that's
what I was thinking and thanks for confirming that. I was already
going to be confused reading that you could do it with normal
JUnitTest. Thanks for pointing that out, and also thanks for the hint
that the test case has to be under .client. package (or change the
settings in the gwt.xml)
@ SeanC: thanks for your contribution. I was trying to use it here in
my GWTTestCase but got this exception.
Compiler is asking about 'com.foo.gwt.client.test.EventUtils'
Checking for JavaScript native methods
[ERROR] No JavaScript body found for native method 'static
native void fireMouseOverEvent(com.google.gwt.user.client.Element
elementToMouseOver)' in type 'class
com.foo.gwt.client.test.EventUtils'
Do you have any idea what is going wrong?
My test looks like this
public class BasicTest extends GWTTestCase{
public void testOnClick() {
ListBox searchTypeLink = new ListBox();
ChangeListener searchTypeLinkChangeListener = new ChangeListener(){
public void onChange(Widget sender) {
}
};
searchTypeLink.addChangeListener(searchTypeLinkChangeListener);
RootPanel rootPanel = RootPanel.get(null);
rootPanel.add(searchTypeLink);
EventUtils.sendClickEvent(searchTypeLink);
assertEquals("On Click to Select", "selectedserachlink",
searchTypeLink.getStyleName());
rootPanel.remove(searchTypeLink);
}
public String getModuleName() {
return "com.foo.psi.Psi";
}
}
I understand that your EventUtils is the tool you have to use to test
UI widgets and their behaviour, right? Can you provide more test
samples on how to use it and how it works?
Thanks guys for your participation in this thread.
Dominik
SeanC
but at a guess I'd say that it's because the /*-{ is not all on the
same line, see /*- is on one line and the { is on the next line.
On Mar 5, 3:59 pm, "dominik_steiner" <Dominik.Stei...@partner.bmw-
> I understand that yourEventUtilsis the tool you have to use to test
> UI widgets and their behaviour, right? Can you provide more test
> samples on how to use it and how it works?
>
> Thanks guys for your participation in this thread.
>
> Dominik
> On 5 Mrz., 10:22, "SeanC" <scree...@gmail.com> wrote:
>
>
>
> > > UI testing is a different
> > > matter because you often find yourself wanting to perform screen comparisons
> > > and event injection which we do not support.
>
> > on the event creation I use the below code to create events in my
> > unittests, excuse the code inEventUtilsas it is a work in progress.
> > > - Show quoted text -- Hide quoted text -
Dominik Steiner
wow, thanks for the reply.
Yes, you were right, the /*-{ was the problem.
Thanks for getting back to me.
Dominik
> ...
>
> read more »