Win a copy of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 this week in the Java in General forum!

Jeff Barnard

Greenhorn
+ Follow
since Nov 24, 2008
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jeff Barnard

My SWT application has been used in both Windows XP/Vista/7 and Mac OSX for several years.

Recently, in certain org.eclipse.jface.action.Action classes I've added the option to open *.txt files (these are newly created operational reports). The files are opened by calling org.eclipse.swt.program.Program.launch(fileName), where fileName is the full path name for a particular *.txt file.

In Windows, there are no issues with this scenario.

In Mac OSX, if the user first launches the text-related program (e.g., TextEdit) before launching my SWT application, there are no issues with this scenario.

In Mac OSX, if the user first exits the text-related program (e.g., TextEdit) launched by my SWT application before attempting to exit my SWT application (via menu's "Quit", etc.), there are no issues with this scenario.

In Mac OSX, if the users does not exit the text-related program (e.g., TextEdit) launched by my SWT application before attempting to exit my SWT application, my SWT application's window closes... but the icon is left behind in the Dock (a.k.a., system taskbar) and my SWT application has not actually exited. I have to manually terminate my SWT application via Force Quit.

Any suggestions about this problem would be welcome.
9 years ago
I finally figured it out:

I replaced the Text within Action class with a ControlContribution class, and the height problem is fixed.

So thanks for your help, and I'll close out this discussion.
10 years ago
First to answer the question: I was following the template that can be seen in my 1/21 code... adding actions in createToolBarManager() via toolBarManager.add(). The only difference is that all the other actions are associated with icons, while this new action is associated with a text field.

By the way, since the ApplicationWindow uses org.eclipse.jface.window.Window.open(), I have overridden this method (and org.eclipse.jface.window.Window.runEventLoop()) and calling the TextFieldAction() constructor just after calling org.eclipse.swt.widgets.Shell.open(). This finally gets the text field to appear in the toolbar (thanks for your help)- at the wrong location !

So now I can be picky... I have managed to move the field to the right end of the other toolbar icons, but would prefer to have it at a particular location in the middle of those icons. My current constructor is captured below:



So my followup request is to see if there's any way for this text field to be at a particular location in the middle of the toolbar's action icons.
10 years ago
Thanks for the suggestion and link... I am familiar with the SWT Gentle Intro series (very useful).

createToolItem() needs to refer to the ToolBar (true for even an overridden method), which hasn't been created at this point in the ApplicationWindow initialization (as can be seen in the modified code below).



If I'm not missing something (which is quite likely), I'm starting to surmise that I need to add the TextFieldAction to the ToolBar after the ApplicationWindow initialization has opened the Shell window.

Please let me know if I've missed something...
11 years ago
Lance,

Not a problem on the confusion, I'm not explaining things well enough

I previously tried adding a read-only text field- but I know (now) I was doing it incorrectly- so here's another attempt...

The problem is that constructing the org.eclipse.swt.widgets.Text requires a org.eclipse.swt.widgets.Composite- and I'm unclear as to what that "parent" Composite should be, since the shell hasn't been created yet and the getToolBarControl.getParent() hasn't been set yet:



Thanks for your continuing input
11 years ago
Lance,

Thanks for replying- and I apologize for my delay on this (had to deal with some other firefights before coming back to this problem).

Question:

put addStatusLine() in your constructor


... please clarify which constructor- if you mean the ApplicationWindow, then that StatusLine is already being used for other purposes. There is a high preference for this status/text window to be in the ToolBar (right beside the control action icon related to that status). My current implementation uses the following code flow to add the tool bar and it's icons/actions:



So do I need to code a major redesign to follow your suggestion, or am I missing something?

Thanks again for any input,
Jeff
11 years ago
It's been awhile since I last asked for help here, but I'm still good at getting lost in Java ...

I want to add a text field that I can update as a status in org.eclipse.swt.widgets.ToolBar (since it's the most intuitive location- right beside the control action related to that status).

I am implementing an org.eclipse.jface.window.ApplicationWindow using the standard setup, as shown in <http://www.ibm.com/developerworks/opensource/library/os-jface1/index.html>, where I'm calling the org.eclipse.jface.action.ToolBarManager.add() method to populate actions in the ToolBar similar to the (working) example shown in <https://coderanch.com/t/509741/GUI/java/Images-not-showing-up-JFace#2304348>.

The problem is I can't seem to find the appropriate class to implement this text field. I seem to have difficulty using org.eclipse.jface.action.StatusLineContributionItem (only shows red missing icon indication) and trying to add org.eclipse.swt.widgets.Text to the new action class is confusing (no parent composite exists until AFTER the window is opened- and calling the setText() method causes threadId contention).

I would welcome any and all ideas for a simple solution to this problem.
11 years ago

Originally posted by James Sabre:


This will lead to tears. String should not be used as containers for binary data as for many character encodings it is not reversible. If you have to have a String version, and most of the time one does not, then you should Base64 or Hex encode the bytes of the ciphertext.



Whoops! Didn't see this entry until now... and I think this is my problem. Thanks for the heads up!
13 years ago
I guess I'm not being clear...



The "key material of the secret key" printed out from m_keySpec.getEncoded() is different each time I startup this application. Is this because each time the SecretKeySpec() constructor is called, it generates new key material? This secret key is used via the m_cipher.init(<whatever mode>, m_keySpec) call, and the subsequent encrypt-into-database/decrypt-from-database results differ each time I start up this application (defeating the whole purpose behind encrypting).

So... do I need to save somewhere the SecretKeySpec data instead of using a hardcoded (or generated) key?
13 years ago
I fully agree with Ulf and have already created a hardcoded key using byte[]. Per Pat, I don't plan to ask the user for a key, and neither do I plan to store a key (since it's hardcoded).

So what am I trying to do? Below is an implementation similar to the one I'm attempting... the critical question is how to use the SAME key (i.e., keyBytes or something else) to call in m_cipher.init()? Note that the TODO label is the location where the key is newly GENERATED everytime- something I do NOT want to do. This is because the data encrypted in the database may have used a different GENERATED key (I want a hardcoded key, not a GENERATED key). Any help would be appreciated:

=====================================================

private static Cipher m_cipher = null;
private static SecretKeySpec m_keySpec = null;

private static void initEncryption() throws Exception {
final byte[] keyBytes = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16};
//TODO: how can I use a hardcoded (not GENERATED) key each time?
m_keySpec = new SecretKeySpec(keyBytes, "AES");
System.out.println("Key: " + asHex(m_keySpec.getEncoded()));
m_cipher = Cipher.getInstance(m_keySpec.getAlgorithm());
}

public static String decryptString(String encrypted) throws Exception {
System.out.println("decryptString- input text: " + encrypted);
byte[] input = encrypted.getBytes();
String decryptedText = null;
byte[] decryptedByte = null;

m_cipher.init(Cipher.DECRYPT_MODE, m_keySpec);
decryptedByte = m_cipher.doFinal(input);

decryptedText = new String(decryptedByte);
System.out.println("decrypted text: " + decryptedText);

return decryptedText;
}

public static String encryptString(String decrypted) throws Exception {
System.out.println("encryptString- input text: " + decrypted);
byte[] input = decrypted.getBytes();
String encryptedText = null;
byte[] encryptedByte = null;

m_cipher.init(Cipher.ENCRYPT_MODE, m_keySpec);
encryptedByte = m_cipher.doFinal(input);

encryptedText = new String(encryptedByte);
System.out.println("encrypted text: " + encryptedText);

return encryptedText;
}
13 years ago
I am new to encryption, and have a big puzzle: I want to encrypt a password into a database using a self-defined key (so I can avoid storing it in a file for later decryption use). I can't seem to find an example of a class that doesn't create a key for me (remember, I already have my own key). I know that this isn't the most secure way to do things, but it's a short-term solution until I have more time to do the job right.
13 years ago