Steve Stevenson

Greenhorn
+ Follow
since Apr 12, 2012
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
1
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Steve Stevenson

Darryl Burke wrote:Rob Camick has a blog post about that. If you want more flexibility, you can find my additions to Rob's design here.


Nice link! It answered my question and then it answered it again with another method that felt more secure!
11 years ago
I am using a JTextPane within a JScrollPane to display more text than the area provides. The controls live on a custom JDialog box and everything is fully initialized in the dialog's constructor. The scroll bars work and allow me to scroll around and view all of the text, but the problem is that the scrollbar is initialized at the lowest position. In other words, when my dialog appears the text field is scrolled down and displays the bottom of the block of text instead of the top.

The first thing I tried to do was set the vertical scrollbar's value to 0 after setting up the dialog, but the request is ignored. I thought this might be the result of the dialog being resized with "pack()" so I called this after pack() and it is still ignored.
As far as I can tell something happens after the dialog's constructor that changes this setting and wipes out mind, but I don't know what it is.




I rigged up the code to perform this command in one of my event handlers so that I could test it completely outside the initialization process and it worked fine, although if I check the current value I see that it's 176 instead of 0. That proves to me that something outside of my doing has moved it. Also, I have found that the size of the scrollpane changes from (410, 120) within the dialog's constructor to (420, 130). I thought this might be due to the appearance of the scrollbars but it is not. I changed the flags from the ..._SCROLLBAR_AS_NEEDED to the ..._SCROLLBAR_ALWAYS flags and the values continued to be as I see them. The min and max values always remain the same with min being 307 and max being 0.




At this point I am thinking that the only way to reposition my scrollbar to the top is to rig up some InvokeLater request, but I'd rather not have my text field appear to "bounce" after initialization.

11 years ago

Bear Bibeault wrote:

Paul Clapham wrote:and you will find that 90% of JavaScript code is indeed crap.


Methinks the man is overly optimistic.

JavaScript is one of the most widely used languages on the planet, yet one that is misunderstood by the vast majority of people using it. Its abuse ratio is likely higher than most other languages. I feel bad for it at times.



That's the main reason the language scares me. With a lot of that stuff I mentioned it would only be dangerous if people abuse it, and I'm afraid of being thrown into a project with abused code. I've been in that situation with strongly-protected and regulated languages like C++ and it's awful getting stuck with some spaghetti code. If JavaScript is abuse-prone it... just kinda scares me.

Bear Bibeault wrote:Jeanne addressed your last point. Is JavaScript your first scripting language? Your first loosely typed language? Your first language outside of Java? The things that seem to be horrifying you are not unique to JavaScript, but are properties of most loosely-typed scripting languages.



I have to be honest here and say "I don't know". I really don't!
I used an old Basic language back in the 80s, learned Pascal (which was strongly typed from what I remember), and then went into the C++ thing where I was for a long time. I seem to remember doing something with a loosely typed variable and believe that may have been my little detour with Visual Basic or the time I had to write a couple simple ASP pages. At any rate, if I had used a loosely-typed language it has been virtually wiped from my memory and effectively leaves me in the same position as someone who has never used one.


Bear Bibeault wrote:
The goals of such languages are brevity and flexibility.

It'd take far too much time to justify each and every reason that scripting languages are as loosely constructed as they are, or to give examples of the benefits that they provide. That's what books are for. I don't know what books you are using, but I'd recommend Head First JavaScript, JavaScript: The Good Parts, and my own book Secrets of the JavaScript Ninja (written with John Resig and currently in early access prior to publishing) in that order.



You actually responded to the thread while I was mentioning this. I'm using "JavaScript 24-Hour Trainer" and think it's great, and then after that I'm going to read "JavaScript: The Good Parts" (So don't spoil the ending for me).



To a use pop culture reference: "Let go, Luke." You need to let go of your preconceived notions to use the Force.



Yea! I think next time I open the book I will need to take a nice long deep breath!

Mark Spritzler wrote:Steve, I have the same basic feelings as you. I am very big about doing things that makes it easy to understand the code and maintain it, and some of the things that can happen in JavaScript because of its "design" allows for some bad things.

That's why Eric told me to read "JavaScript the Good Parts" (Which I finished last night for the first read through. I need more than one read through). Because there is some great power in how Javascript is designed to help you write web applications, in which Javascript was built for. So as Bear says it is designed that way because it is best for what it is used for in web applications. I can imagine if Javascript was built like a statically typed language and like Java then things like closures, function callbacks, asynchronous code wouldn't be as simple as it is in JavaScript.

And most JavaScript programmers know to avoid creating global variables. You know it is also easy to create global variables in Java and it is just as bad an idea.

Basically, I have problems because I have to think differently and sometimes hack to get something to work like I want in JavaScript, where I don't have those issues in Java. And that JavaScript sometimes makes me write code that I cringe at because I would never ever want to do that same design in Java. But if I was using Pascal, which it type safe, I also would use a completely different design.

Mark



Thanks! Now I know I'm not alone with being bothered by some of these things!
Thanks for the suggestion on that book too because I am going to order it. It's always a gamble when you buy these kinds of books online because the reviews on Amazon are often limited and could have been written by the author's mother! Right now I'm reading Wrox's "JavaScript 24 Hour Trainer" and have found it to be laid out well, easily understandable, and the video lessons are helpful too, but it's always a good idea to hit these topics from another angle to get some information from another point of view.

Jeanne Boyarsky wrote:Most of the things that horrify you are features of scripting languages in general. Search for weak typed and dynamic languages. Examples include Python and Ruby.

This isn't bad; just different. Scripting languages aren't rare or a one off. They are an important concept to understand. Also, learning different types of languages makes you a better programmer because you learn to think differently about problems.

And your reaction is inexperience. Don't let that bother you. Think of it is learning a new programming concept rather than being horrified. This also shows you want to be a software developer not just a "Java programmer". The former has flexibility.




I think one of my big problems is how through my years with C++ and now Java I have become overly aggressive in protecting my data to ensure accidents can't happen. Not only do those languages require you to explicitly defining your variables, you can even lock them from being edited (final, const, etc), fine tune the range of data (i.e. unsigned), and use the data types to prevent inappropriate data from being passed from function to function. I love how those features can virtually eliminate an entire category of potential bugs, and it does scare me that those safeguards are gone in exchange for yet-unknown benefits. I know scripting languages are basically compiled on-the-fly by web browsers so there have to be differences, but I just don't know if it's wise for so many long-established safeguards to be abandoned because the code is written in a scripting language.

Bear Bibeault wrote:Let me just say that if you approach JavaScript from the point of view that it is somehow "Java lite*" you will be very confused. It is its own language and all those properties that seem to violate your sensibilities make it a powerful and flexible language.



That is how I started, but the huge differences became apparent so quickly that I researched the issue just to see how the language even got the name "JavaScript". I even wondered if there had been some sort of a legal dispute over this name, so it was interesting to read how it was designed to complement the internet experience that Java was providing web browsers.


I'd highly recommend starting over without the perception that JavaScript has anything at all to do with any other language built for a completely different purpose. Keep an open mind and you might find that, for the purpose for which it is intended, JavaScript is an elegant and powerful language.



At this point my problems with the language don't have anything to do with the fact it isn't Java-Lite. It has to do with the fact that the language seems to openly embrace things that other languages specifically forbid and forbid partially because of the bugs that it can introduce. For example, I'd be curious to know the benefit of creating a new variable in the global namespace when an undeclared variable is used, and why that benefit cannot be gained with the use of safer syntax. I'd also like to know how that benefit (if there is one) outweighs the problems that can be caused with a simple typo. A lot of the odd stuff in JavaScript can be done in other languages, but only with proper safeguards in place.



I'd also highly recommend that you should learn how to couch a discussion in reasonable terms rather than just bad-mouthing things you clearly do not understand. Your post comes across as rather unprofessional.



That's a highly simplistic view on the post that I wrote. "Badmouthing" and "critiquing" and two related yet different concepts, and had I wanted to badmouth the language I would not have articulated numerous examples of the problems I have encountered with it nor would I have openly admitted (I forget how many times) that I am new and that I may be missing things. Also keep in mind that it is also rather unprofessional to remain silent and not speak out against something you see as being problematic. Yes, I may have been a little passionate, but so far the only response I've received addressing my issues with the language has been an answer to the most superficial thing I brought up: the name.



* Changing the name of the language from LiveScript to JavaScript back in the mid 1990's was a huge mistake as it gives people the idea that it's somehow related to Java. Except for a syntax influenced by C syntax, they have very little else in common.



I read somewhere that the name "Mocha" was considered, but at any rate at this point I've gone beyond having issues with the name and wonder how the loss of long-established programming practices and safeguards can be a good thing. I loved that picture by the way!
Not knowing any internet scripting languages I decided to learn JavaScript. Programmer job postings always request it and a headhunter recommended I learn it so I bought a book. I was expecting a Java-lite experience but it appears to be anything but! My problem is that I repeatedly learn something new, my mouth drops from the horror of its design, I blow off my reaction as inexperience, and then my open-mindedness is punished with learning how yet another core programming concept has been bastardized in JavaScript.

At this point I've learned something so horrific I am forced to post and ask: Does this language ever make any sense? So far it seems like the designers grabbed some C++/Java keywords and digitized some bubble gum and popsicle sticks and voila! JavaScript was born! I am so thoroughly confused by the overall design that I can't even tell if there even is a design.

The first shocker was the loosely-typed language design. Aside from making things appear less threatening to new programmers does this have any actual benefits? If you know enough about your variable to be able to name it then shouldn't you know what kind of data it will hold? Shouldn't you even know that before you create the name? So I blew off my reaction as inexperience only to learn about functions: any function can return whatever it wants whether it's a string, number, nothing, or even another function! This can all happen even within the same function! The function's parameter list does not specify data types so there's no protection against accidentally passing in arguments in the wrong order.

After that I learned that you don't really need to end a statement with a semicolon because the parser will know what you mean, and that if you misspell a variable name then you have nothing to fear because JavaScript will help you by creating a brand-new variable for you IN THE GLOBAL SCOPE because that's what you really wanted. Since JavaScript really has no such thing as data types it really doesn't need all the pomp and circumstance in creating a variable properly anyway!


The straw that broke the camel's back came yesterday and has halted my progress: Objects. Apparently objects are also generic "var" data types and your "class" (I use that term loosely since it doesn't appear to be a keyword) is "defined" completely on the fly: if your object needs a new member variable then voila! Just refer to it and it will magically appear out of thin air!

So instead of doing something like this crude pseudo code:




In JavaScript you can do this, right?:


I mean, is that actually right?
That's gonna work great for those times people misspell things and suddenly have girl.sibling, girl.silbling, girl.sidlnig all living in the object.


The deeper I get into JavaScript the worse it seems to get. I honestly don't know if it's possible to make decent, sensible, maintainable code with JavaScript or even if I want to continue learning this language and possibly put myself into a position where I must maintain some code. It certainly helps explain why websites can be so error prone. Am I missing something here? Is there an elegance to JavaScript that will eventually become apparent or is it really as sloppy and dangerous as it appears?
One of the things I absolutely HATED as a programming in VC++ for Microsoft operating systems was a design oversight in the design of the menu system. In Windows, a menu item has a position index and a unique id unless it was the base of a submenu! Then it had no unique ID! Therefore if you had to access a popup menu programatically, like to disable it or the options within it, you had to know its position number. This drove me nuts because it was so imprecise: in a multi-developer environment someone could easily rearrange the items, localization teams could rearrange things to improve readibility for other languages, and different build configurations (retail, trial, debug, etc) could have different menu items. Computers are supposed to be precise: IDs are precise. They are constant. They are permanently locked to whatever it is they are identifying. Positions are not! Positions are arbitrary and can change on a whim! I even sent complaints about this to Microsoft only to get a response back basically saying that they weren't going to fix it.

So boy was it nice to see that the Java developers actually decided to do this right.

Today I wanted to know how to enable/disable menu items within a "File" menu on the fly, and *surprise surprise* Java actually allows you to reference that File submenu with a variable assigned to that exact item. Wow! Who'd have thunk it? I didn't have to grab the menu item at position 0 and pray to god that this position was actually my "File" menu: The File menu is the File menu by virtue of being the actual freaking File menu! Someone could move this menu item to the middle, the end, or to the moon and this code will still work.

Granted, this issue is probably a pet peeve that many others may never have even cared about or even noticed, but this isn't the first time I noticed that programming concept I always found clumsy or poorly thought from my old programming life was designed with common sense in Java.

11 years ago

Stephan van Hulst wrote:Submitting Callables to an ExecutorService seems perfect for this task.

Create a Callable class that returns an image from its call() method. You can then cancel and timeout the task through the Future class.
Here you can change the timeout between loading images in another thread (make timeout and timeunit volatile) and they will affect the next image being loaded. You should allow the user to cancel a task explicitly by providing a cancel button that calls currentTask.cancel().



Wow, I have never seen that class before so I will have to take a look at what that is. Thanks!
I have a thread that basically loads an image from a disc, waits for a period of time to expire, and then loads another image. The duration between images is user-defined and can be adjusted within the program. I'm trying to figure out the proper way to do this.


Currently I have what I consider a bit of a kludge. Say the duration is 10 seconds, what I do is sleep for 1 second intervals in a loop and constantly check on each loop to see if I've exceeded the user's delay preference. This works, but is this inefficient?


What I think is the proper way is to use the interrupt() command and handle its InterruptedException exception. That way I would initially put that thread to sleep for the full 10 second period and then if the user changes the duration I would interrupt the thread, calculate the amount of time necessary to sleep for the user's new preference (assuming the duration was extended), and then sleep for that amount.


The only problem with going in this direction is that I don't know why InterruptedException occurred. Aside from the user changing the duration, any other time I get this InterruptedException I want to handle this by ending the thread. I know I can use some custom flags to kludge my way around this, but removing kludges is the goal here.


Any recommendations?

Darryl Burke wrote:

Steve Stevenson wrote:Another surprising thing is that there doesn't seem to be a resize notification for containers; it only seems like the notification is available for components.


java.awt.Container extends java.awt.Component. Every Container is-a Component.



Hum... I didn't think of that. It is somewhat strange that I found comments online of people saying it wasn't working properly for objects known as being containers, but then again it's possible other things could have been preventing this.


I'm still loving the fact that this issue introduced me to invokeLater. I had seen it before but never looked into it, and all this time I had been wishing for something along the lines of PostMessage from the Windows API. Now I'm planning to overuse and abuse that function a little bit
11 years ago
I'm actually surprised that there isn't a simple solution that involves having a layout manager handle this automatically. Since there wasn't, and Michael Dunn's example was both dodgy and dicey (Thanks for the demo anyway it was useful to test out and it did work without any problems) I have decided just to listen for resize notifications on the outer panel. Another surprising thing is that there doesn't seem to be a resize notification for containers; it only seems like the notification is available for components. Fortunately that wasn't an issue today, but someday that seems like it will be an issue.
11 years ago