Develop Reference

Opening a TCL gui within Java code

I have a TCL file which uses Tcl's BWidget package that I've been using as a GUI for my program. I now want to be able to load up this GUI from a separate Java program. I've looked into Jacl and Swank, but they don't seem to do exactly what I want.
I've tried the following with Jacl but it's unable to evaluate the file. While debugging, I can see that it completes parsing my tcl file, but it throws an exception while parsing through the BWidget package tcl files. Here's my Java code:
Interp interp = new Interp();
try {
interp.evalFile("C:\\CTP\\Tcl\\LuxonCtp32.tcl");
} catch (TclException ex) {
int code = ex.getCompletionCode();
System.err.println("command returned bad error code: " + code);
} finally {
interp.dispose();
}
Any ideas on how I can accomplish what I want to do? Is it even possible?

Tcl itself can not display a GUI. It uses a plugin called Tk for that.
In the C reference implementation of Tcl you get Tk as well.
Tk has not been ported to Java, Tcl has.
You can not use Jacl to display Tk widgets, but TclBlend could do that, because TclBlend uses the C reference implementation of Tcl. That means that the user needs a working Tcl/Tk installation.
There are some problems with TclBlend and Tcl > 8.5 through, which result in a segfault.
IIRC you have to remove the conditional if around Tcl_FindNameOfExecutable in TclBlends C code (and compile it yourself).

Go to this site http://jtcl-project.github.io/jtcl/ and download now for the binary zip. Its a recent java tcl on github called Jtcl.
Unzip it and you will find a jar called jtcl-2.7.0.jar.
I am using Netbeans 8 my preference.
I add the jar into Project Library.
I create a java file called JTclHallo.java and this is the code.
package jtclhallo;
// import tcl.lang it belongs to jtcl-2.7.0 jar a must
import tcl.lang.*;
// Java wrapper to test JACL or JTCL.
public class JTclHallo {
public static void main(String []args) {
//Interp is a java class belonging to tcl.lang. Unrar the jtcl-2.7.0
Interp i = new Interp();
try {
//call your tcl file mine was swing.tcl from the E drive
i.eval("source E:/private/swing.tcl");
} catch (TclException e) {
System.out.println("Exception: " + e.getMessage());
}
}
}
For swing.tcl
package require java
set window [java::new javax.swing.JFrame]
$window setSize 600 400
$window setVisible true

Webpage Java Applet - Open On Screen Keyboard

I'm trying to open the On Screen Keyboard from within a web application on a touch screen interface. I am using Opera as the browser for the built in "Kiosk" features, but it does not support VBScript- an easy way of openning a .exe file from a webpage.
I know Java can be ran from within a web page and it can also be used to open another application, such as the OSK!
Below is my working Java code:
package runtimeexec;
import java.io.IOException;
public class RuntimeExec {
public static void main(String[] args) {
try {
Runtime runTime = Runtime.getRuntime();
Process process = runTime.exec("cmd /c osk");
} catch (IOException e) {
e.printStackTrace();
}
}
}
Now I want to embed this into a webpage, so that it can open the osk. My .class file is at http://theyconfuse.me/java/runtimeexec/RuntimeExec.class and my current attempt to embed this code is at http://theyconfuse.me/java/ with the following embed code:
<applet codebase="http://theyconfuse.me/java/runtimeexec" code="RuntimeExec.class" width="200" height="200"></applet>
How ever, when I load the page, I get the following:
NoClassDefFoundError
RuntimeExec (wrong name: runtimeexec/RuntimeExec)
Can anyone help me with what am I missing here? Thanks

code="RuntimeExec.class"
Should be with package structure, separated by dots, but without the .class extension.
code="runtimeexec.RuntimeExec"

What am i supposed to Import? Hello World Program

Im completely new to Jogl and Java and what am i supposed to Import in this Hello world program? Thanks!
public class HelloWorld
{ // open HelloWorld
public static void main (String args[])
{ // open main
try
{ // open try
System.loadLibrary("jogl");
System.out.println("Hello World! (The native libraries are installed.)");
} // close try
catch (Exception e) // all try's need a catch
{ } // even if the catch does nothing
} // close main
} // close HelloWorld

For that particular code, I don't think you need to import anything. The only package you use is System which is already available to you.
If you want to do more complicated stuff, you'll probably need, at a minimum:
import net.java.games.jogl.*
although you could no doubt exert a finer-grained control than that, by importing specific stuff.

If you are not going to do anything other than print that string then no need for other imports. Importing is only necessary if your using it in your program like BufferedReader, etc.

Trouble with ProcessBuilder

Following code opens status very fine in notepad:
import java.util.*;
class test
{
public static void main(String args[])
{
try{
ProcessBuilder pb=new ProcessBuilder("notepad","F:/status");
pb.start();
}catch(Exception e)
{
System.out.println(e);
}
}
}
Following code does'not play the song:
import java.util.*;
class test
{
public static void main(String args[])
{
try{
ProcessBuilder pb=new ProcessBuilder("C:/Program Files (x86)/VideoLAN/VLC/vlc","D:/02 Tu Jaane Na");
pb.start();
}catch(Exception e)
{
System.out.println(e);
}
}
}

I think that the problem is that you're ignoring the fact that the files you're trying to open have filename extensions.
Windows Explorer doesn't display file extensions by default - that is probably why you are not aware of their existence.
The reason why notepad worked in your first example is that notepad automatically adds .txt extension to its filename parameter in case you didn't provide one yourself. So in reality the file that is being open is not status but status.txt.
VLC doesn't have this "advanced" functionality because there's no specific filename extension it is designed to work with.
So you will need to look up the dir command output and add the full file name as a parameter.
If that was the real issue - you might want to modify your Windows Explorer settings for it to display file extensions:
or, which is better, switch to a more programmer-friendly OS :)

For 1.6+ code, use Desktop.open(File) instead.
Of course, the sensible thing to do immediately before calling that is to check File.exists().
OTOH, Desktop.open(File) throws a slew of handy exceptions, including:
NullPointerException - if file is null
IllegalArgumentException - if the specified file doesn't exist
UnsupportedOperationException - if the current platform does not support the Desktop.Action.OPEN action
IOException - if the specified file has no associated application or the associated application fails to be launched
Properly handled, the exception would indicate the immediate problem.
As an aside, the Desktop class is designed to be cross-platform, and will handle any file type for which an association is defined. In that sense it is a lot more useful for something like this, than trying to use a Process.

java.awt.Desktop.open doesn’t work with PDF files?

It looks like I cannot use Desktop.open() on PDF files regardless of location. Here's a small test program:
package com.example.bugs;
import java.awt.Desktop;
import java.io.File;
import java.io.IOException;
public class DesktopOpenBug {
static public void main(String[] args)
{
try {
Desktop desktop = null;
// Before more Desktop API is used, first check
// whether the API is supported by this particular
// virtual machine (VM) on this particular host.
if (Desktop.isDesktopSupported()) {
desktop = Desktop.getDesktop();
for (String path : args)
{
File file = new File(path);
System.out.println("Opening "+file);
desktop.open(file);
}
}
} catch (IOException e) {
e.printStackTrace();
}
}
}
If I run DesktopOpenBug with arguments c:\tmp\zz1.txt c:\tmp\zz.xml c:\tmp\ss.pdf (3 files I happen to have lying around) I get this result: (the .txt and .xml files open up fine)
Opening c:\tmp\zz1.txt
Opening c:\tmp\zz.xml
Opening c:\tmp\ss.pdf
java.io.IOException: Failed to open file:/c:/tmp/ss.pdf. Error message:
The parameter is incorrect.
at sun.awt.windows.WDesktopPeer.ShellExecute(Unknown Source)
at sun.awt.windows.WDesktopPeer.open(Unknown Source)
at java.awt.Desktop.open(Unknown Source)
at com.example.bugs.DesktopOpenBug.main(DesktopOpenBug.java:21)
What the heck is going on? I'm running WinXP, I can type "c:\tmp\ss.pdf" at the command prompt and it opens up just fine.
edit: if this is an example of Sun Java bug #6764271 please help by voting for it. What a pain. >:(

I never knew about this Desktop command, untill recently through this post:
would Java's Runtime.getRuntime().exec() run on windows 7?
Previously i have been using:
Runtime.getRuntime().exec("rundll32 SHELL32.DLL,ShellExec_RunDLL "+ myfile);
And it has always worked for me. If your method does not work, may be you can think about try this command.

If you switch the order of your arugments does that cause one of the other files to get that same error. I wonder if you need to trim the end of the path before calling the File constructor.
umm...yeah ignore that... check the documentation of Desktop.open. open throws an IO exception "if the specified file has no associated application or the associated application fails to be launched " ... also from the top of the page... "The mechanism of registereing, accessing, and launching the associated application is platform-dependent. "
code for the Desktop class: http://fuseyism.com/classpath/doc/java/awt/Desktop-source.html
The open method calls DesktopPeer.open.
DesktopPeer source: http://www.jdocs.com/javase/7.b12/java/awt/peer/DesktopPeer.html
DesktopPeer is implementation specific.
Here is source for a Windows-specific implementation:
http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Platform/windows/sun/awt/windows/WDesktopPeer.java.htm
open->ShellExecute->(Native)ShellExecute
Native ShellExecute is a wrapper for Win32 ShellExecute. Here is info on the function.
http://msdn.microsoft.com/en-us/library/bb762153(VS.85).aspx
My suggestion for a work around would be to write your own implmentation of the ShellExecute function. Here is source from someone who did it. http://www.heimetli.ch/shellexec.html