|
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.
|
|
|
|
|
The JRE requires a method with the signature:
public static void main(String [] args)
It must be public, or else it can't be accessed.
It must be static as it is called before anything has been instantiated.
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
|
|
|
|
|
Nagy Vilmos wrote: The JRE requires a method with the signature
If you are using Java 1.5 or later you can also use the signature:
<br />
public static void main(String... args)<br />
There is a difference between the two, although not really significant for a main method. The following works with the vararg signature, not with the array signature:
<br />
MyClass.main("A", "B");<br />
This will not compile if you are using the main(String[] args) form. But how often do you do this with a main method anyway?
|
|
|
|
|
j
modified on Tuesday, September 13, 2011 8:00 AM
|
|
|
|
|
This is far too much code for anyone to read through. Explain what you are trying to do, what fails, and where it goes wrong.
|
|
|
|
|
I'll give you some general tips to start with:
0. The client needs to run on two threads, one to receive messages and one to send. Normally the main thread will be the sending thread and also the UI.
1. I would separate the communication from the processing into two classes. Have another class in the server, something like ClientSession that deals with any logic. This would have the name of the client session and a reference to the main chat server.
2. As with the connection, the server should be separated into UI and logic. By having these separated it will eb clearer to see what is what. A simple call-back from the server will update the UI.
3. Check your names, you have so many different styles it becomes confusing. Do not use underscores. All variables should use camel case likeThis and classes should be pascal case ThisWay.
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
|
|
|
|
|
if(ddirection > 8.00)
{
direction = Direction.DOWN;
}
if(ddirection < 0.00)
{
direction = Direction.UP;
}
if(direction == Direction.UP)
{
ddirection = ddirection + 0.05;
}
else
{
ddirection = ddirection + 0.05;
}
I am trying to make the double ddirection go up and down between 8.0 and 0.0
The above code does not work. What else can i do?
Direction is an enum, containing UP and DOWN. direction is a variable of type Direction.
|
|
|
|
|
How does it not work, is ddirection a local variable or a class one. If it is a local one what is the initial value.
That being said why are you doing the same thing in the direction == Direction.UP if block as in the else block.
|
|
|
|
|
I am not sure quite what your values may be for this variable, but if you want it to lie only within the range 0.0 to 8.0, then what is wrong with:
if(ddirection > 8.00)
{
ddirection = 8.00;
}
else if(ddirection < 0.00)
{
ddirection = 0.00;
}
|
|
|
|
|
Member 7991625 wrote: What else can i do?
fix it.
1. there is a blatant mistake, actually a very small one (about the size of half a character) with big consequences. And you should have gathered it by observing the actual behavior (or simply by reading the code, which is what you made us do).
2. once the big error is fixed, there still is a little extra flaw: you have organized it such that you first need to get outside the valid range in order to change directions. That isn't very good, you should predict you're going to leave the range and then prevent that.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
