|
flashery wrote: Anyway its just ButtonGroup not JRadioButtonGroup.
Sorry about that, my brain's currently running in safe-mode (ie. debugging some VB apps)
Excuse me for my improper grammar and typos.
It's because English is my primary language, not my first language.
My first languages are C# and Java.
VB, ASP, JS, PHP and SQL are my second language.
Indonesian came as my third language.
My fourth language? I'm still creating it, I'll let you know when it's done! 
|
|
|
|
|
|
|
|
Hello again, its been a while since I post here I am making a Timer application in java. Which shutdown the PC on specified time.
My problem is it is showing a warning
Note: C:\Users\flashery\Documents\NetBeansProjects\Timer\src\MainTimer.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
How do I do this recompiling?
Can someone give me a hint on this thing.. 
|
|
|
|
|
Just add that option to your javac command, or project options in NetBeans. Alternatively find the deprecated method you are calling and change it for the latest version; the documentation will tell you how.
BTW the link in your title links back here.
|
|
|
|
|
Thanks Richard MacCutchan it really helps me.
For those who don't know here's the details
It's just for NetBeans IDE 7.0.1 I don't know how to do it on other IDE.
1. Right click on your project you can see it on the left side of the IDE project tab and select properties.
2. In the project property window just click compiling on the left side of the window.
3. Find this option after clicking the compiling "Additional Compiling Options:" it is located on the lowest side and add your compiling option in my case I add this on the textbox.
-Xlint:deprecation
4. Click OK and your done.
5. Try debugging your project and your will see a message like this on the output option of debugging.
C:\Users\flashery\Documents\NetBeansProjects\Timer\src\MainTimer.java:93: warning: [deprecation] disable() in javax.swing.JComponent has been deprecated
cmbTime.disable();
C:\Users\flashery\Documents\NetBeansProjects\Timer\src\MainTimer.java:190: warning: [deprecation] disable() in javax.swing.JComponent has been deprecated
cmbTime.disable();
C:\Users\flashery\Documents\NetBeansProjects\Timer\src\MainTimer.java:206: warning: [deprecation] enable() in javax.swing.JComponent has been deprecated
cmbTime.enable();
Hope this helps. I really google it and there's no detailed info on how to do it. I am thankful to Richard MacCutchan for saying its on the project option.
|
|
|
|
|
I am providing an interface to one of my products as a 'C' language DLL, compiled using Microsoft Visual Studio 2008. The interface may be used in a Java application. I don't know Java, so I could use some guidance on things I need to do in my DLL to make it as easy to use as possible.
The functions in my DLL only take arguments in the form of 32-bit signed integers, pointers to integers, and constant UNICODE (const wchar_t*) strings, and return 32-bit signed integers. I would like to let them use callback functions with similar signatures. The target environment could be Windows XP, Windows 7 (32-bit), or Windows 7 (64-bit).
I've done some preliminary reading, and it appears that Java Native Access[^] (JNA) is the easiest way for a Java client to use functions in a DLL like this.
Are there any gotchas I need to be aware of?
Software Zen: delete this;
|
|
|
|
|
Personally I would fully encapsulate the DLL.
Where I've done this before, I have used a pure interface class mapping to the dll, but kept it package level.
Then create a public class that accesses the DLL.
This gives future proofing, for example if you need to move to a new version of windows and the API [shock! horror!] changes you only need to update the internal DLL interface and not the entire project.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
Hmm. I should have made this clearer.
I'm mainly concerned about how to do things in the functions the DLL provides:
Are const wchar_t * strings okay? Or should I use const char *, and insist on UTF-8 encoding (these are things like file paths)?
I assume returning values via int * arguments will work?
Can I use callback functions? I have asynchronous events that I would like to use a callback function for. The caller would pass the DLL a function pointer, which I would then call as needed for an event.
Software Zen: delete this;
|
|
|
|
|
|
Very  Richard. I had seen the JNA, but hadn't read too much about it. Thanks!
Software Zen: delete this;
|
|
|
|
|
Thanks; I have only used JNI myself, and although it's a bit of a learning curve it works well. From my reading of the JNA documentation that may be an easier option.
|
|
|
|
|
I don't actually want to give the users of this DLL the Java required to use it. They have a pronounced case of "Not Invented Here" syndrome. I'm just trying to reduce the amount of grief I get from them.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: I don't actually want to give the users of this DLL the Java required to use it.
In that case they will have to write it (via JNA/JNI) themselves; but that is their choice. Alternatively you could ask them to give you the Java code they want to use and then you (or someone who knows Java) write the interface to the DLL. Ultimately one of you will have to produce the Java specification and code.
|
|
|
|
|
what happen when main method is declare private?
SGS
|
|
|
|
|
Sarika G Shinde wrote: what happen when main method is declare private?
The Java run time will not be able to find it. It's declared public and static for a reason; that is, so the JRE can load it by finding the method via reflection without needing to know any specific details about the class other than its name.
|
|
|
|
|
One slight err. When you build a jar, the main class is declared so the JRE knows exactly which method to call..
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
Yes, I had not considered jars (see below), but that's because it's not obvious which class in the jar has the main method.
Normally when I think of jars I have ![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif) in mind.
|
|
|
|
|
Nagy Vilmos wrote: When you build a jar, the main class is declared so the JRE knows exactly which method to call..
No.
When you build an 'executable jar' that is the case. And there are generally other constraints that one must deal with when creating that specialized jar.
Most jars are not of that type but can certainly have a main method. Actually they can have many main methods since each class can have one.
|
|
|
|
|
I think Willie's answer was quite correct in the context of this question.
|
|
|
|
|
Re-reading several times I still don't see that.
|
|
|
|
|
Well since you confirm it in the first sentence of your response I cannot understand what it is that you don't see.
|
|
|
|
|
Because 'jar' does not equal 'executable jar'
No more than 'programming language' equals 'java'.
In each the second is is a subset of the first.
In each there are many more cases of the first than the second.
In each there are many specific details that impact the second.
|
|
|
|
|
I said "within the context of this question" where it is fairly obvious we (i.e. everyone except you) are talking about executables.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
