Ditch JBuilder 3.
There's no reason whatsoever to still use that dinosaur.
Hamrick commented: That was uncalled for. +0
jwenting 1,905 duckman Team Colleague
Ditch JBuilder 3.
There's no reason whatsoever to still use that dinosaur.
aaargh, darn site is way too slow to post the reply and ends up posting it twice.
If you know English, kiddo, show it and don't think you're "kewl" or something by trying to use text messaging shorthand which is highly annoying and only shows that you're an immature little kid who's too lazy to even think.
Indeed there is no "best". Do you think anything else would survive in the market if one program was "best" in such a way that it alone was suitable for anything and everything?
At most there may be a "best" program for a specific task in a specific environment for use by people with specific training.
But most likely even that is not the case and there's a host of applications to choose from that all will do an adequate job, the choice depending on personal preference of those making the decisions.
if you don't know English well enough to understand books and websites written in it, learn it before going further as you WILL need it.
by finding out what "core Java" is.
yup. typically will send a character representation of the screen (ASCII Art forever!) to the parallel port.
You obviously don't return the values to the page for display after you handle them.
Windows might play nice and provide an abstraction layer which makes the command window perceive the mouse as a serial device, but I'm far from certain about that.
and what hardware architecture, what mouse (USB, PS/2, serial, something else maybe).
I've done it 15 years or so ago. At the time we had to write our own mousedrivers, was fun.
I think the disk with that code is by now unreadable (not that it would do much good of course as hardware and operating systems have progressed rather a lot since).
No, Java can't create directories under DOS for the very simple reason that Java doesn't work under DOS.
no, it is NOT urgent.
The thing to do is to read the documentation, which explains it all in detail.
The steps for using ANT to retrieve the WSDL and generate your classes has already been outlined above though not every option you could use mentioned, use the manual to find out about those.
this has nothing to do with JSP...
And you seem to have defined your instance (I hope) variable conn as being of the wrong type.
Anyway, what you're doing is terrible. You should never open connections to external resources at a different place from where you're going to close them.
Doing so is a recipe for disaster.
The solution is to use the correct memory model for your project (see your compiler manual pages for details of how to do that).
A better solution is to use a modern 32-bit compiler and join the rest of the real world.
And the best solution is to do both :)
libsdl is a better choice than BGI since it has a host of functions and has better tutorials and support on the internet than BGI.
Whatever it is, it's a better choice if it supports 32 bit environments as BGI is 16 bit only :)
The basic game engine should not contain any display related code.
Write everything without a display system and then write a display system you can plug that code into.
Make both independent of the other and have some interface between them.
The file can't be deleted due to the lock in this case.
That depends on the operating system and the user permissions on that operating system...
On Windows it's indeed hard (but not imposssible) to remove an open file, on Linux it's quite possible.
lockfiles are extremely risky.
What if the running instance of the application crashes (or the computer it's running on crashes which has the same effect)?
The lockfile will still be there when you start it again, causing it to never start until the file is manually removed.
And what if some smartass finds out where the file is and removes it while the application is running? Now he can run as many instances as he wants side by side.
hmm, our system has several thousand classes.
Can't remember them all right now, but I seem to recall something representing a stock, a stockmarket, a stockquote, a trade, etc. etc.
Maybe it's time to admit to your employer that you lied on your resume when you told them you were an experienced designer.
JavaMail is included in the J2EE API which Websphere application server implements. So yes, it knows it.
It's just a question of setting up your classpath correctly for your editor/IDE to also know what you're talking about.
The manual (which you'll have if you indeed bought Websphere Studio which you're probably talking about) will tell you all about that.
If you didn't buy it why should we help you use pirated software?
Or jar. jar can not just create jar files, it can also read and extract them.
never assume a servlet's constructor will be called.
In fact unless it's a no-args constructor it's guaranteed to not be called!
Typically a servlet is instantiated once, when it is first needed, per member of a cluster (which means once for most people, as most people don't run their applications in a clustered environment).
After that the servlet engine will keep it in memory and launch a new thread for each time a service method on that servlet is requested to be executed.
idiotic and highly dangerous to have anything in place that can bypass the normal request/response system and call any method it wants directly.
Security leaks guaranteed, such a thing is a major billboard with all flashing light for crackers, giving them complete root access to your machine at their leasure.
like I said, you don't realise what you're dealing with here.
What you're effectively saying is that you want to call private method on a class without having access to an instance of that class.
Even if you had an instance you'd be hard pressed to call that method (there are ways, but they're only for experts).
Think of trying to use the car stereo in the car of someone in another country to listen, from your own bedroom, to a CD that's sitting on your neighbour's kitchen table who's on vacation and you don't have the key to his door.
And oh, that car stereo doesn't have a CD player and the car is turned off so the stereo has no power.
yes. I have tons of ideas.
And no, what you're thinking of doing isn't going to work (at least not in the way you probably think to do it).
nesting jarfiles isn't supported.
There are some proposals to allow for it, but nothing has yet reached prototype stage.
So at current the only way would indeed be to unpack the jars into one folder and repack them as a single archive.
Better (usually) to just add them all separately to your classpath.
It's a very rare case where there is a need to repack jars, usually it's only applicable when deploying packages to an application server where they would interfere with older versions of those same packages that the application server needs internally, a situation rare enough that most people never encounter it (I myself only have seen it once so far in a decade of using Java professionally).
Wow... I didn't know that.
it's not something the greens want known, it would ruin their agenda...
The electricity to charge those batteries is produced in coal fired powerstations in most areas.
Those aren't exactly clean. Then there are all the line losses before it gets to your house where you charge your car. Those line losses amount to over 30%, up to 70% in some areas.
In total only 5-10% at most of the caloric value of the fuel used to generate that electricity is actually used for propulsion of you "green" electric car.
With a petrol engine that's something like 50-60% (even taking into account the losses during transportation of the fuel to the gas station, something not taken into account with the calculation for electricity).
Take into account that petrol burns cleaner than does coal, and that it's easier to tune a car engine for optimum efficiency than a powerstation, and the effect becomes clear.
Of course if the car is powered using electricity from a nuclear powerstation (or hydro) the equation changes.
But hydro has its own drawbacks, many of which are only now becoming recognised.
The lakes behind hydro dams cause massive destruction of pristine wilderness, destruction of habitat on a massive scale and regularly cause species to go extinct.
The dams can also prevent species like salmon from reaching their spawning grounds.
Wind, tidal, als solar also have major drawbacks that aren't often mentioned …
Filled her up 2 weeks ago for €1.42 per liter, highway prices were €1.51 per liter.
Things have gotten more expensive since, up to €1.45 or so per liter now here, €1.60 on the highway.
That's $8.21 per gallon, give or take a few cents.
if you can't find anything about session management and JSP you haven't looked...
You may want to just limit your form's memory to cookies... which you can handle with Javascript...
you don't. Leave it to the server to decide what session storage system to use. It will use cookies if needed and possible, other systems as required.
There's rarely a requirement to set a cookie explicitly, just about the only time is if you want to persist something across sessions clientside.
If you DO resort to using sessions for non-logged in users, be careful to use them wisely, and clear unused data as soon as it is no longer valid...
which is pointless to do explicitly as it's automatically done for you. The session expires after a period of time and whenever the user closes his browser window he no longer has access to it.
This is a serious problem for many developers...
Hardly. I've worked with JSP and servlets for a decade and that's never been a problem even on high volume online banking sites I've worked on.
Of course any halfway decent developer knows what's to be stored in a session and what's not.
He'll not store things there that aren't needed across requests for example, unless maybe if retrieving that data is very expensive.
forum etiquette both here and elsewhere says you share your insights when you find a solution.
Strings aren't arrays, arrays aren't strings.
What's the difference between a basketball and a barbequeue?
seems his keyboard is stuck...
post only the relevant parts of your code. Noone's going to look through hundreds to thousands of lines of code to find the few where the core problems are.
is the write order of the bytes the same as the read order?
Sun's is best overall.
Jikes is reported to be a bit faster at times, but has some quirks that make it not quite standards compliant.
None of the others come even close (though the one in Eclipse tries).
that's because you cannot use those keywords inside methods.
You will need to add the correct declarations to the top of your JSP to enable JSTL.
That will have to be accompanied by a correctly versioned web.xml in order to get the servlet container to initialise support for JSTL correctly.
well, for one thing you're using an assignment operation where you're probably intending to use a comparison operation.
And that comparison operation would also be incorrect as it's not the way to compare Strings in Java.
<c:choose>
<c:when test="incidents.INC_STATUS == 'open'">
<option value="OPEN" selected="selected"/>
<option value="CLOSED"/>
</c:when>
<c:otherwise>
<option value="OPEN"/>
<option value="CLOSED" selected="selected"/>
</c:otherwise>
</c:choose>
would be a proper way to do it in JSP (though there are some variations on the theme, like determining whether to set an option to true in that option, which is the best way if the number of options gets to be more than two or three).
in general: Do NOT use that. There's almost never a need to use Runtime.exec or any of the other methods from the Runtime class unless maybe you're writing a compiler or classloader.
Using File works fine, IF you have rights to delete the files.
If you don't, running a del command should not work either.
but beware Herb Schildt's book is generally considered NOT very good and contains some glaring errors (including statements that directly contradict the language standard as published by Sun).
and that's your problem. One should never be content with a mere passing grade in one of his chosen majors.
if you "just don't get" an introductory Java course, and are happy with a C overall, you may need to reconsider your career choices and switch to another line of studies.
May sound harsh, but that's the long and short of it, as with those symptoms you'll never amount to more than a lowend programmer stuck with the uninteresting jobs noone else wants to do.
I think you need a tutorial on the use of search engines...
Use Google to look for one :)
600 or so audioCDs, a few dozen of them imported into iTunes for a total of maybe 3GB (which gets deleted and new stuff imported once in a while).
Use iTunes almost exclusively to move stuff from CDs to my iPod so there's no need to retain things there.
nope. the JVM will ONLY load classes it can find on its classpath (and that includes your application classes, if those aren't on the classpath it won't load them).
Best set up the classpath when running the JVM, that way it's local to that instance of the JVM.
That's achieved through the -cp commandline parameter to the Java runtime.
If you talk to the consumer helpdesk or salesrep, they will indeed give you (or sell you) a ready made piece of software (which is what mom and pop want).
You'll need to dig deeper, or maybe go to a specialised company, to get an API.
are you sure your text is being painted in a visible colour, that the text colour isn't somethintg transparent?
contact a service provider, they'll have APIs for you (at a price).
You MUST explicitly initialise all local variables in a method before reading them for the first time.
You don't do that, so you get an error.
Don't use BDE, it's there for legacy support only.
It's no longer maintained, no longer supported.
Anyway, the error is quite clear. It can't find the file.
Could be because of the spaces in the filename, being a very old program (did I tell you it's there for legacy support only and no longer maintained for the last 7 years or so?) it might not know how to deal with those.
Why are you trying to use J2EE classes from J2ME?
And why are you trying to do something with a servlet when you want to connect to a database?
I seriously doubt though that you can connect to a database from J2ME at all, afaik it doesn't support JDBC.
check your loop. Why is there a semi-colon at the end of the line?
It's highly unlikely that it's supposed to be there.