 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / August 2006Java and Microsoft Windows
Someone told me that Java always makes all of its graphical user interface controls from scratch, and never implements its controls as Microsoft Windows controls, is this always true, even for applets that run inside of Internet Explorer? Peter Olcott schrieb: > Someone told me that Java always makes all of its graphical user interface > controls from scratch, and never implements its controls as Microsoft Windows > controls, is this always true, even for applets that run inside of Internet > Explorer? AWT uses native components, SWT too. Swing uses lightweight controls, so they're painted by Swing. Bye Michael > Peter Olcott schrieb: >> Someone told me that Java always makes all of its graphical user interface [quoted text clipped - 7 lines] > Bye > Michael So does Java most often use Microsoft Windows controls (is this what you mean by native components) or does it most often build them from scratch itself? (I am not a Java programmer so I don't know if AWT is the foundation on which Java is based, or some obscure technology that is rarely used). Peter Olcott schrieb: > So does Java most often use Microsoft Windows controls (is this what you mean by > native components) or does it most often build them from scratch itself? (I am > not a Java programmer so I don't know if AWT is the foundation on which Java is > based, or some obscure technology that is rarely used). First of all, Java is a language. Neither AWT nor Swing are part of the language but of the user interface libraries of the "Java Platform". AWT was the first windowing toolkit (Abstract Windowing Toolkit - AWT) included in the Java Platform. Later, Swing was introduced. AWT provides only a very basic set of native components (components that are provided by the underlying system, e. g. Microsoft Windows). Most probably you'll find just a few applications built upon pure AWT. SWT (Standard Widget Toolkit) is a 3rd party library that is part of the Eclipse project. It also uses native components but I don't know if one can use SWT effectively in applets. Swing is based on AWT but paints all components by itself. This way different Look & Feels are supported. But why do you want to know that? Bye Michael > Peter Olcott schrieb: >> So does Java most often use Microsoft Windows controls (is this what you mean [quoted text clipped - 15 lines] > Eclipse project. It also uses native components but I don't know if one can > use SWT effectively in applets. Which of these three technologies is used most often in web applets? > Swing is based on AWT but paints all components by itself. This way different > Look & Feels are supported. > > But why do you want to know that? I am working on an application that must interface with every other application type. > Bye > Michael > "Michael Rauscher" <michlmann@gmx.de> wrote in message .. > Which of these three technologies is used most often in web applets? If the authors have the mistaken impression that coding in AWT will provide support for 'all browsers' (read 'IE + the other one'), they might stick to the limited number of GUI components available in the AWT. If the authors are realistic and need split panes, trees, table support.., they will use either Swing or SWT - which both have a richer GUI component set than AWT. Swing & AWT both come 'packaged with Java' and therefore you can get a Swing/AWT based applet that is <10Kb. If using SWT in an applet, OTOH, the SWT jar needs to be downloaded as a separate archive (transparently to the user - but taking longer). I have neve seen an actual SWT based applet. For that reason I would say - the majority (ever increasing) are Swing, a shrinking number are AWT, & theoretically, you might find one or two that use SWT. > > But why do you want to know that? > > I am working on an application that must interface with every other application > type. What about Swing/SWT/AWT *applications*? Andrew T. >> "Michael Rauscher" <michlmann@gmx.de> wrote in message > .. [quoted text clipped - 23 lines] > are Swing, a shrinking number are AWT, & theoretically, > you might find one or two that use SWT. The current majority of web applets use Swing technology? >> > But why do you want to know that? >> [quoted text clipped - 3 lines] > > What about Swing/SWT/AWT *applications*? Yes, and even YeOlde MSDOS Command Line applications. I must be able to interface to anything. > Andrew T. Peter Olcott schrieb: > The current majority of web applets use Swing technology? With respect to applets that use components that goes beyond simple drawing/animation, I'd say yes. Perhaps you could explain to me what you mean with the following statement you wrote in response to Jeffrey Schwab: > I have invented a way for one application to interface with any other > application. Remote controlling, embedding, ... ? Bye Michael > Peter Olcott schrieb: >> >> The current majority of web applets use Swing technology? > > With respect to applets that use components that goes beyond simple > drawing/animation, I'd say yes. What about ordinary business applications and applets? > Perhaps you could explain to me what you mean with the following statement you > wrote in response to Jeffrey Schwab: [quoted text clipped - 3 lines] > > Remote controlling, embedding, ... ? Universal GUI Scripting Language that can "see" anything on the screen by processing the screen pixels in real time using a deterministic finite automaton. > Bye > Michael >>> I have invented a way for one application to interface with any other >>> application. [quoted text clipped - 3 lines] > processing the screen pixels in real time using a deterministic finite > automaton. Er... Like java.awt.Robot? http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Robot.html >>>> I have invented a way for one application to interface with any other >>>> application. [quoted text clipped - 7 lines] > > http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Robot.html Can it win live action video games on MS Windows and Apple OS? Can it control MS DOS 3.1 applications? Can it always fully automate any application on any platform? Since you referred to it as java.awt.Robot, I would estimate that it would have a hard time with Swing technology, thus it would not even be universal on its own platform, much less every platform. >>>>> I have invented a way for one application to interface with any other >>>>> application. [quoted text clipped - 7 lines] > > Can it win live action video games on MS Windows and Apple OS? Not on its own, of course. You'd have to write some code specific to the game you want to play. If you've written a class that woke up one day and decided to get its own avatar in Second Life, I want a copy. :) > Can it control MS DOS 3.1 applications? Not sure what you mean... Are you talking about Windows 3.1, or Apple DOS 3.1? If you're talking about your program sharing a 286 with actual DOS, my hat's off to you. I wouldn't want to squeeze the J2SE into low RAM. :) > Can it always fully automate any application on any platform? That's a pretty bold claim, but if we're talking about automating GUI functions, I would guess Robot is the most portable engine you're likely to find. > Since you referred to it as java.awt.Robot, I would estimate that it would have > a hard time with Swing technology, thus it would not even be universal on its > own platform, much less every platform. java.awt is just the package where it lives, which makes sense because it needs tight integration with the host environment. Sorry, I guess I wasn't clear enough... Why not read the documentation for yourself? >>>>>> I have invented a way for one application to interface with any other >>>>>> application. [quoted text clipped - 11 lines] > you want to play. If you've written a class that woke up one day and decided > to get its own avatar in Second Life, I want a copy. :) Unless it implements a deterministic finite automaton there is no possible way that it can recognize the arbitrary sets of pixels that video games produce in real time. If it does implement a deterministic finite automaton, to recognize arbitrary sets of pixels in real time for the purpose of controlling another application, then my patent would probably be invalidated by this prior art. >> Can it control MS DOS 3.1 applications? > > Not sure what you mean... Are you talking about Windows 3.1, or Apple DOS > 3.1? If you're talking about your program sharing a 286 with actual DOS, my > hat's off to you. I wouldn't want to squeeze the J2SE into low RAM. :) 1981 Microsoft DOS applications still run under the current versions of MS Windows XP. >> Can it always fully automate any application on any platform? > > That's a pretty bold claim, but if we're talking about automating GUI > functions, I would guess Robot is the most portable engine you're likely to > find. Can it see the exact location and current state of every graphical user interface control element on MS Windows (from 3.1 to XP), and Java Swing? >> Since you referred to it as java.awt.Robot, I would estimate that it would >> have a hard time with Swing technology, thus it would not even be universal [quoted text clipped - 3 lines] > needs tight integration with the host environment. Sorry, I guess I wasn't > clear enough... Why not read the documentation for yourself? So then it can see the current state and exact location of every Swing control element? >>>>>>> I have invented a way for one application to interface with any other >>>>>>> application. [quoted text clipped - 41 lines] > So then it can see the current state and exact location of every Swing control > element? I hope you won't be offended, but may I ask how old you are? >>>>>>>> I have invented a way for one application to interface with any other >>>>>>>> application. [quoted text clipped - 44 lines] > > I hope you won't be offended, but may I ask how old you are? Here is the actual patent, my age is not relevant to the subject at hand. http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=% 2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=7046848.PN.&OS=PN/7046848&RS=PN/7 046848 Can you answer the questions now? > Can you answer the questions now? I'm trying, and so are several other people, just to try to make the group welcoming. Your questions are extremely vague though; you're not making yourself easy to help. :) Do you still have specific questions you would like answered? Btw, your tone comes across as argumentative. It's almost like you're angry with other people for not appreciating the genius that is Peter Olcott. Most of the people here are also pretty bright, so you might want to pretend for a moment that you're speaking with your peers instead of a bunch of hostile inferiors. Catch more software developers with honey, to paraphrase. :) >> Can you answer the questions now? > [quoted text clipped - 8 lines] > moment that you're speaking with your peers instead of a bunch of hostile > inferiors. Catch more software developers with honey, to paraphrase. :) I haven't had nearly the same degree of experience with my interpersonal communication skills, as I have had with my software development skills. I don't mean to seem hostile, and I know that my Java development skills are by far inferior to most everyone here. I have about 17,000 hours and most of my life savings invested in my current project, so I tend to have a little emotional attachment to it. I desperately want this project to succeed. This may tend to make me seem hostile when someone brings up the possibility that there are already alternatives that would make this project useless. If there are alternatives that do make this project useless, then I need to know about these, yet, these must be very rigorously analyzed. The primary benefit that my technology provides is the possibility of a universal scripting language. To the best of my knowledge there is no other technology that can possibly provide a scripting language that is nearly as universal as that provided by my technology. Now is the time that I must definitively ascertain this point. I did not come to this forum to definitively ascertain this point. I came to this forum to validate one single aspect of this point. The single aspect of this point that I came to validate is the difficulty of providing a scripting language that could completely automate any possible Java program. From the best that I can tell, from the expert advice that I received here, even this tiny task would tend to be difficult. The specific aspect of this task that I must analyze is the difficulty of determining the current state and exact location of any graphical user interface control. Since Java has at least three different technologies for creating these controls, a first estimate from my limited point of view would be that even this tiny subtask would require a hodge podge conglomeration of these three technologies. Definitively ascertaining the precise degree of truth of this last statement would fulfill my whole need for being here. > From the best that I can tell, from the expert advice that I received here, even > this tiny task would tend to be difficult. The specific aspect of this task that [quoted text clipped - 3 lines] > limited point of view would be that even this tiny subtask would require a hodge > podge conglomeration of these three technologies. Perhaps I can provide a better answer. There are three commonly used GUI technologies, as you've gathered, but we could be more explicit about the names. They are: - Plain AWT - AWT with Swing - SWT Two of these are based on AWT, and the third is based on SWT. Both AWT and SWT provide the ability to determine the exact location and state of user interface controls from within that application, if you already have a reference to the user interface control. From outside of the application, you'd have to either act like a debugger and ensure the app is running in debug mode, or obtain a handle to a JVM instance via JNI. Neither can be done uncooperatively. So to do this with Java APIs, you need to at least have the cooperation of the application that you wish to interact with. It is not reliable, at least in AWT or AWT/Swing, and probably in SWT as well, to ask the operating system. Lightweight controls in AWT (and this includes all Swing controls except the top-level containers) are not exposed to the operating system, so the OS won't be able to give you their location, nor even know that the control is there. So it is probably not worthwhile to pursue the route of asking the OS. You seem to be interested in recognizing controls based on the equivalent of a screen shot. In this case, you actually need to consider a larger number of cases: for one case per platform (and possibly per JVM implementation) for plain AWT and for SWT, and one case per look and feel for Swing. Since Swing has pluggable look and feels, a component can literally look like anything in the world, depending on which look and feel is in use. Of course, custom components may look different for any of the above. Finally, you keep mentioning your patent. That really sucks. Please don't be part of the problem.  SignatureChris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation >> From the best that I can tell, from the expert advice that I received here, >> even [quoted text clipped - 44 lines] > Finally, you keep mentioning your patent. That really sucks. Please > don't be part of the problem. I have a total of 30,000 hours and most of my life's savings invested in four different software inventions. I work about 85 hours a week. Each of these ideas focused on deriving unique ways to save businesses money. This one is the first one with market potential. I have to have patent protection otherwise a big software company will simply take my idea, and squish my efforts and life savings with their unlimited development and advertising budget. Only because of the possibility of some protection from this do tiny little one-man development companies have any significant chance of surviving. Without patent protection it would not be worth the risk, therefore many innovations would never be created. A patent only lasts 17 years, and then its public domain. > I have to have patent protection otherwise a big software company will simply > take my idea, and squish my efforts and life savings with their unlimited > development and advertising budget. > > Only because of the possibility of some protection from this do tiny little > one-man development companies have any significant chance of surviving. Plenty of one-person development companies survive. I'm sorry if you don't think you can be one of them. Obstructing the rest of the world is still not an ethical response. > Without patent protection it would not be worth the risk, therefore many > innovations would never be created. A patent only lasts 17 years, and then its > public domain. Only 17 years? Do you realize what software looked like 17 years ago? Do you realize what it would look like now if everyone had patented what they did 17 years ago? You are part of the problem. SignatureChris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation >> I have to have patent protection otherwise a big software company will simply >> take my idea, and squish my efforts and life savings with their unlimited [quoted text clipped - 16 lines] > > You are part of the problem. Confession: I'm a co-inventor on half a dozen computer architecture patents, only one of which has passed the 17 year limit. I don't see anything unethical about my employer wanting ownership of a design they paid for. Patricia >>> I have to have patent protection otherwise a big software company will >>> simply take my idea, and squish my efforts and life savings with their [quoted text clipped - 24 lines] > > Patricia If it was not for patent protection we would still be in the dark ages, no light bulb would ever exist. Patent protection is provided to put enough incentive in the unreasonably grueling efforts required to significantly advance the current state of technology. > Confession: I'm a co-inventor on half a dozen computer architecture > patents, only one of which has passed the 17 year limit. > > I don't see anything unethical about my employer wanting ownership of a > design they paid for. This is getting well off-topic (which is my fault... sorry), but neither do I. It is when your employer claims legal rights over people who independently happen to do things the same way that things get shaky. Empirically, though, this tends not to happen so much with physical inventions. It happens daily with software patents. For this reason, rather than for any theoretical distinction, I object more to software patents than physical patents. I would agree, though, if you wanted to say that the real problem in both cases is that the patent office needs to have the expertise to decide whether the advantages to society outweigh the disadvantages for a given patent before they grant it. In any case, I shoulda kept my mouth shut and just not provided any help. SignatureChris Smith >> Confession: I'm a co-inventor on half a dozen computer architecture >> patents, only one of which has passed the 17 year limit. [quoted text clipped - 12 lines] > to have the expertise to decide whether the advantages to society > outweigh the disadvantages for a given patent before they grant it. That is not how patents work. They never make this kind of determination. All that they are required to determine is whether or not anyone has come up with this idea before, and whether or not this idea is obvious in light of prior ideas. Since 98% of patents never make any money, they would be wasting alot of time trying to figure out the degree of benefit to society, 98% of the time there is no benefit to anyone. If software patents are not allowed, then no one would spent the 30,000 and hundreds of thousands of dollars deriving the technology of my patent. Thus society would never reap the benefit of this technology. Preliminary estimates indicate that this technology is able save business billions of dollars every year. If it was not for software patents these billions of dollars would simply be wasted. Seventeen years from now this technology will be public domain. > In any case, I shoulda kept my mouth shut and just not provided any > help. > That is not how patents work. They never make this kind of determination. All > that they are required to determine is whether or not anyone has come up with > this idea before, and whether or not this idea is obvious in light of prior > ideas. Unfortunately, you are right that the patent office never makes any kind of judgement about whether it's a good idea to grant a patent before they do so. They are supposed to do so; indeed, the constitution grants them their power only for the purpose of advancing the useful arts and sciences. Current regulations say that they fulfill that duty by assessing whether an idea follows naturally from the current state of knowledge, or is truly a breakthrough. The obviousness standard, though, has been watered down to the point that it is a joke. This is partly due to our inability to fund the patent office (in real dollars, the office spends per patent less than 3% what it did in the first decade after it was formed, and less than it has at any time in history), and partly due to the mistaken concept that patents somehow fit under property rights. As for your "invention", let's just say that (I didn't realize this when you first posted here, but have since looked around) you are clearly something of a crackpot, and your billions of dollars number is hinging on completely laughable. I didn't look at your patent, but you apparently didn't publish anything about it so it must not be too awfully theoretically interesting. Yes, it still appears you are part of the problem; albeit at least not maliciously so. SignatureChris Smith >> That is not how patents work. They never make this kind of determination. All >> that they are required to determine is whether or not anyone has come up with [quoted text clipped - 18 lines] > you first posted here, but have since looked around) you are clearly > something of a crackpot, and your billions of dollars number is hinging I thought that this sounded unreasonably high myself until I actually ran the numbers. It is estimated that my technology will save 1/3 of business computer users at least 5 minutes a day, there are 75 million business users in the United States alone (US Census data 2003). This boils down to 25 million people times 21 hours per year, or 525 million labor hours saved per year. Even at minimum wage this is billions of dollars. The crucial assumption upon which this result rests is the estimate of five minutes for 25 million people. I verified a marketing research time and motion study design with three Ph.D. marketing research professors, and all three said that the design was good, and would seem to produce valid statistically generalizable results. I will perform at least one of these studies before I launch. > on completely laughable. I didn't look at your patent, but you > apparently didn't publish anything about it so it must not be too > awfully theoretically interesting. Yes, it still appears you are part > of the problem; albeit at least not maliciously so. >> I have to have patent protection otherwise a big software company will simply >> take my idea, and squish my efforts and life savings with their unlimited [quoted text clipped - 17 lines] > > You are part of the problem. My software technology will save businesses billions of dollars every year. If I could not get patent protection, I would have never developed it. No one else would have ever gotten around to developing it, thus society comes out many billions of dollars ahead only because of patent protection. If it was not for patent protection most of the technology that you see today would not exist. It would have been too risky to spend enough time to get it fully developed. Even the automobile might never exist, if it was not for patent protection. Edison might have never bothered to invent the light bulb, if he knew someone else could take his idea for free. Why work eighteen hours a day for many years for free? Why bother? >>>>>> I have invented a way for one application to interface with any other >>>>>> application. [quoted text clipped - 31 lines] > needs tight integration with the host environment. Sorry, I guess I wasn't > clear enough... Why not read the documentation for yourself? To know that a system lacks a capability requires a much deeper understanding than finding out if a system has a capability. This deeper understanding takes a lot of time. I am already working 85 hours a week, so I find that simply asking people that already know these things is a much more cost-effective use of my time. > Since you referred to it as java.awt.Robot, I would estimate that it > would have a hard time with Swing technology, thus it would not even be > universal on its own platform, much less every platform. Don't confuse the methods used to implement its functions with the scope of those functions. How does your solution interact with a native RetroForth system running without multi-MB OS on the bare metal? s. >> Since you referred to it as java.awt.Robot, I would estimate that it >> would have a hard time with Swing technology, thus it would not even be [quoted text clipped - 7 lines] > > s. When the slave application is running as a segregated part of this multi-megabyte OS it can interface perfectly. >>> Since you referred to it as java.awt.Robot, I would estimate that it >>> would have a hard time with Swing technology, thus it would not even be [quoted text clipped - 10 lines] > When the slave application is running as a segregated part of this > multi-megabyte OS it can interface perfectly. That is the difference between *every platform* and *current versions of Windows*. FYI: Many DOS-based applications interfacing directly to the hardware do *not* run on modern Windows systems any more, as the access has been severely restricted (already with NT4, IIRC). Take care, s. >>>> Since you referred to it as java.awt.Robot, I would estimate that it >>>> would have a hard time with Swing technology, thus it would not even be [quoted text clipped - 20 lines] > Take care, > s. By every platform, I mean MS Windows including all MSDOS applications that still run under MS Windows, also any software that will run under the current versions of Apple OS, or Linux. Basically any software that will run under any modern GUI OS. >>>> I have invented a way for one application to interface with any other >>>> application. [quoted text clipped - 7 lines] > > http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Robot.html I didn't see anything that enabled it to form anything like the basis for a universal scripting language in this documentation. Although there is capability for operating the user interface input hardware, there did not seem to be any capability to "see" graphical objects on the screen. Capturing the screen is not at all like intelligently recognizing the current state and location of graphical user interface control elements. Without this ability, no universal graphical user interface scripting language would be possible. Perhaps there are many more deeper levels to this documentation than this link seems to indicate. Peter Olcott schrieb: >> Peter Olcott schrieb: >>> The current majority of web applets use Swing technology? >> With respect to applets that use components that goes beyond simple >> drawing/animation, I'd say yes. > > What about ordinary business applications and applets? Applications: Swing. Applets: here you have to separate between (I'd say) decorative applets that are used to beautify homepages and applets that are part of serious applications. The former are most often implemented using AWT, the latter use Swing. IMO. >> Perhaps you could explain to me what you mean with the following statement you >> wrote in response to Jeffrey Schwab: [quoted text clipped - 6 lines] > processing the screen pixels in real time using a deterministic finite > automaton. Ah, and you want to know if it's possible to do the same using Java? I'd say 'yes' with respect to the language Java. E.g. it shouldn't be a big problem using JNI (the interface to the native system) to get window handles and so on. Bye Michael > Peter Olcott schrieb: >>> Peter Olcott schrieb: [quoted text clipped - 26 lines] > using JNI (the interface to the native system) to get window handles and so > on. The technology that I invented can obtain the current location and state of graphical user interface controls for literally anything. I want to know the degree to which another set of methods might be able to accomplish this same result, in other words the degree of competition that I might have in the future. Is there any technology(ies) within Java that can always obtain the exact state and current location of any Java based controls? What is the name of this technology(ies) > Bye > Michael > The technology that I invented can obtain the current location and state of > graphical user interface controls for literally anything. I want to know the > degree to which another set of methods might be able to accomplish this same > result, in other words the degree of competition that I might have in the > future. So what if my Swing application had a picture of a button, but no actual button? Would it think it was a button? What if my L&F displayed buttons or textfields with no identifying marks other than just text? How would your technology know the difference? Would it think it was just text? You see, my Swing application creates only a single native OS peer, and that's a window. There are no other component peers. So you can't get to my other components via the OS, you can only attempt a screen scrape and hope that my buttons and textfields, etc. look the way you think a button should look like. > Is there any technology(ies) within Java that can always obtain the exact state > and current location of any Java based controls? What is the name of this > technology(ies) None. >> The technology that I invented can obtain the current location and state of >> graphical user interface controls for literally anything. I want to know the [quoted text clipped - 4 lines] > So what if my Swing application had a picture of a button, but no > actual button? Would it think it was a button? It would consider anything at all to be a graphical user interface control iff (if and only if) it was specifically informed that it is to be considered a graphical user interface control. If you make a bitmap that is identical to the bitmap of a legitimate graphical user interface control, then it would be required to use other contextual information to disambiguate this case. > What if my L&F displayed buttons or textfields with no identifying > marks other than just text? How would your technology know the > difference? Would it think it was just text? Typically textfields are demarked in one way or another. If you don't somehow identify a textfield as a text field, then a human user will not know that it is a text field. If there is enough displayed on the screen for a person to tell that it is a text field, then various methods can be used so that my technology would identify it as a text field as well. Generally if its good enough for a person, then its good enough for my technology. > You see, my Swing application creates only a single native OS peer, and > that's a window. There are no other component peers. So you can't get > to my other components via the OS, you can only attempt a screen scrape > and hope that my buttons and textfields, etc. look the way you think a > button should look like. It would simply look at your specific button, then (when told) would know that this bitmap in this context is a button. >> Is there any technology(ies) within Java that can always obtain the exact >> state >> and current location of any Java based controls? What is the name of this >> technology(ies) > > None. That is very good news for me. Let's see how many others concur. > Typically textfields are demarked in one way or another. If you don't > somehow identify a textfield as a text field, then a human user will not [quoted text clipped - 3 lines] > Generally if its good enough for a person, then its good enough for my > technology. Then take a look at Squeak's Morphic framework, please. It contains a sample of a TextMorph presenting rotated text in an arbitrary shape. A human will recognize that this is a "text field". How would you recognize a hyperlink if it was presented without decoration and only revealed itself upon being touched by the mouse pointer? A human would learn to sweep the mouse over the page to discover active spots. At least I have done so, as I tend to click on corporate logos in top web page corners in the hope of being transferred to the home page. Contextual information is not rectangular. s. >> Typically textfields are demarked in one way or another. If you don't >> somehow identify a textfield as a text field, then a human user will not [quoted text clipped - 7 lines] > sample of a TextMorph presenting rotated text in an arbitrary shape. A > human will recognize that this is a "text field". My process is deterministic, only a stochastic process could recognize this sort of thing, but, with stochastic processes, the 100% reliability and real-time response rate goes away. My system could recognize any possibly rotated text, iff it was provided an exact sample of the end-result of the rotation, and informed of the intended value associated with this pixel pattern. > How would you recognize a hyperlink if it was presented without decoration > and only revealed itself upon being touched by the mouse pointer? A human > would learn to sweep the mouse over the page to discover active spots. At > least I have done so, as I tend to click on corporate logos in top web > page corners in the hope of being transferred to the home page. Same method for my system. The goal here is a universal scripting language. Scripts written in this scripting language would be written by people that understand the nature and details of what is being scripted. Because of this the author would generally know in advance which links are relevant to the task at hand, and the pixel pattern associated with these links. Alternatively the system could scan the whole page noting all of the hotspots from changes to the pixel patterns displayed on the screen. > Contextual information is not rectangular. > > s. >>> Typically textfields are demarked in one way or another. If you don't >>> somehow identify a textfield as a text field, then a human user will [quoted text clipped - 14 lines] > end-result of the rotation, and informed of the intended value > associated with this pixel pattern. Speaking of reliability ... have you noticed the last sentence of claim 15 on the web page of your patent? Does your software really "invoice" the second program? >> How would you recognize a hyperlink if it was presented without >> decoration and only revealed itself upon being touched by the mouse [quoted text clipped - 9 lines] > are relevant to the task at hand, and the pixel pattern associated with > these links. Then what's the advantage to just parsing the HTML? In this specific context? > Alternatively the system could scan the whole page noting > all of the hotspots from changes to the pixel patterns displayed on the > screen. Do you want to move the mouse over every pixel? That would be about a million on my screen, and you'd have to *wait* for a possibly slow browser (running on a multitasked system) to really respond to the event. There goes the real time response. >> Contextual information is not rectangular. Maybe we just have different notions of "universal", Horatio. s >>>> Typically textfields are demarked in one way or another. If you don't >>>> somehow identify a textfield as a text field, then a human user will [quoted text clipped - 18 lines] > on the web page of your patent? Does your software really "invoice" the > second program? I did not notice this mistake. I just confirmed that this mistake was made by the UTPTO. All of my material that was sent to them says "invoke". I will have them fix this immediately. >>> How would you recognize a hyperlink if it was presented without >>> decoration and only revealed itself upon being touched by the mouse [quoted text clipped - 11 lines] > > Then what's the advantage to just parsing the HTML? In this specific context? The goal is to provide a UNIVERSAL scripting language solution, and since HTML is only one of many possible interfaces it would be far from universal. My technology enables a universal scripting language for any application that takes its input from one or more user input hardware devices and interacts with the user through the display screen. >> Alternatively the system could scan the whole page noting >> all of the hotspots from changes to the pixel patterns displayed on the [quoted text clipped - 4 lines] > on a multitasked system) to really respond to the event. There goes the real > time response. It has the same limitations as a person, if a link is not visually identified to a person, most people will miss it too. >>> Contextual information is not rectangular. > > Maybe we just have different notions of "universal", Horatio. > > s ... > It has the same limitations as a person, if a link is not visually identified to > a person, most people will miss it too. Remember that people have natural language understanding capability. A piece of text can say something that indicates to a human that it is likely to be a link. To attain universality, your program has to work regardless of the choice of natural language. What is the Chinese for "click here for ..."? Even among web pages with distinctive formatting for links, the difference can be anything. Patricia > ... >> It has the same limitations as a person, if a link is not visually identified [quoted text clipped - 10 lines] > > Patricia UNIVERSAL meaning that it will work correctly for every application on any platform. Any scripting language requires a programmer to tell it what to do. It can recognize all the text on the screen simultaneously while recognizing everything else, regardless of the size, color, or font (or even language) of the graphical objects. >> ... >>> It has the same limitations as a person, if a link is not visually identified [quoted text clipped - 15 lines] > everything else, regardless of the size, color, or font (or even language) of > the graphical objects. In that case, why are you concerned with the innards of the Java GUI? From the previous paragraph it sounds like you're just working with the pixel array scraped from the display device and therefore your invention shouldn't care at all about the programming language, support libraries or operating system. If I've understood you correctly it should also work with the content of a window displaying the output from an application run remotely under the control of any of the following: - PC Anywhere (remote Windows display) - VNC (*nix graphical) - an X-term server, e.g. exceed (both *nix graphical and *nix console textual output) - telnet (*nix textual output) - ssh client (*nix textual output) - IBM 3270 (mainframe textual terminal emulator) - IBM 5250 (AS/400 textual terminal emulator) - Kermit (textual output from an application under ANY remote OS that supports Kermit) I'm using *nix as a shorthand for any UNIX-like OS: in other words Linux, Mac OS-X, AIX, HP-UX or any other SVR4 UNIX. Have I understood you correctly? Signaturemartin@ | Martin Gregorie gregorie. | Essex, UK org | Hi, Peter Olcott schrieb: > Is there any technology(ies) within Java that can always obtain the exact state > and current location of any Java based controls? Perhaps you're more familiar with C. So, what would you answer if I asked you the same question with respect to C? Probably you'd tell me, that C doesn't even know anything of controls. C is a language. Sure, there are libraries like the MFC but these aren't part of the language C. The same applies to Java. There are libraries like AWT, Swing and SWT but they aren't part of the language Java. If the Java runtime libraries don't offer what you need, you can use JNI to write Java native methods. From the JNI specification: The JNI is a native programming interface. It allows Java code that runs inside a Java Virtual Machine (VM) to interoperate with applications and libraries written in other programming languages, such as C, C++, and assembly. Bye Michael > Hi, > [quoted text clipped - 23 lines] > Bye > Michael This answer seems to indicate that it might be possible within the set of everything pertaining to Java to always obtain the exact location and state of any graphical user interface control. Peter Olcott schrieb: > This answer seems to indicate that it might be possible within the set of > everything pertaining to Java to always obtain the exact location and state of > any graphical user interface control. Yes. The only thing I'm in doubt is that it's possible just by using the standard runtime libraries. > Peter Olcott schrieb: >> [quoted text clipped - 4 lines] > Yes. The only thing I'm in doubt is that it's possible just by using the > standard runtime libraries. I need to have a completely definitive answer before this question has been sufficiently answered for my needs. For example another respondent answered with the opposite answer. This means that the criterion measure for an affirmative answer must be the details of the specific means to accomplish this. Hopefully someone will provide this, or alternatively most everyone else will confirm that it can't be done. >> Peter Olcott schrieb: >>> [quoted text clipped - 11 lines] > accomplish this. Hopefully someone will provide this, or alternatively > most everyone else will confirm that it can't be done. There are too many variables in your statement of the problem to provide a "completely definitive" answer: "might" be possible -- rubber word -> answer yes, probability low "within ... Java" -- a real constraint to "always" obtain -- my programs kill jvms upon startup -> answer no "exact location and "state" -- as in 'enabled' or 'disabled'? of "any ... control" -- invisible ones, too? There *are* invisible GUI controls, you know. Screen corners have been used to dynamically (de)activate screen savers on Macintosh way back in System 6 days. s. >>> Peter Olcott schrieb: >>>> [quoted text clipped - 14 lines] > There are too many variables in your statement of the problem to > provide a "completely definitive" answer: How about this one: Within the goal of determining the exact location and current state of any GUI control within every Java program, which cases of addressing this goal do not have specific solutions for GUI controls that have a visible location and visible state? > "might" be possible -- rubber word -> answer yes, probability > low [quoted text clipped - 9 lines] > > s. Peter Olcott schrieb: >> Peter Olcott schrieb: >>> This answer seems to indicate that it might be possible within the set of [quoted text clipped - 6 lines] > sufficiently answered for my needs. For example another respondent answered with > the opposite answer. This means that the criterion measure for an affirmative I said "yes" to "it might be possible". To me "within everything pertaining to Java" includes the Java language, the Java Platform and in particular the JNI, too. So, if one can provide a DLL that is able to "always obtain the exact location and state of any graphical user interface control" and one can use the functions of this DLL by wrapping them with Java native methods, then it might be possible. With regard to the "opposite answer": this is most probably the consequence of different interpretations of your question. E.g. "within Java" is a very unclear statement to me. It could mean anything from the language to the platform, with JNI/without JNI... Bye Michael > Peter Olcott schrieb: >>> Peter Olcott schrieb: [quoted text clipped - 12 lines] > Java" includes the Java language, the Java Platform and in particular the JNI, > too. A definitive affirmative answer requires specific methodology. > So, if one can provide a DLL that is able to "always obtain the exact location > and state of any graphical user interface control" and one can use the [quoted text clipped - 6 lines] > E.g. "within Java" is a very unclear statement to me. It could mean anything > from the language to the platform, with JNI/without JNI... Anything that is in any way directly or indirectly related to the Java programming language. How about we simplify this specification and merely say: Is there any possible way by any means generally available to the public to always obtain the current state and location of every graphical user interface control by one program pertaining to another program? This question is not even restricted to Java, but, feel free to restrict your answer to Java if you want. > Bye > Michael Peter Olcott schrieb: > How about we simplify this specification and merely say: Is there any possible > way by any means generally available to the public to always obtain the current > state and location of every graphical user interface control by one program > pertaining to another program? OK, this makes life easier since I can give a short, definitive answer: I don't know. Bye Michael > Peter Olcott schrieb: >> How about we simplify this specification and merely say: Is there any [quoted text clipped - 7 lines] > Bye > Michael To what extent do you know? Can you name one specific way that one program of any kind can obtain the current location and current state of the graphical user interface controls of another program that is a Java program? Peter Olcott schrieb: > To what extent do you know? To what I've written in previous posts: there's a way to use native functions from within Java applications. > Can you name one specific way that one program of any kind can obtain the > current location and current state of the graphical user interface controls of > another program that is a Java program? I don't know. In fact, meanwhile I don't even know what you're trying to figure out (I assume that there aren't any side constraints): - 100 % pure Java code can solve the problem: I'd say most probably no. - there's a way for a Java application to use a solution: yes - most probably - if one can provide (native) code that solves the problem. - there's a way to solve the problem in particular with respect to Java/Swing applications: I don't know but as you stated that your technology works with any application, you should know it. Bye Michael > Peter Olcott schrieb: >> To what extent do you know? [quoted text clipped - 17 lines] > applications: I don't know but as you stated that your technology works with > any application, you should know it. My method processes screen pixels, it does not need to understand the internals of anything. I am trying to determine is the extent that competitors could use alternative methods to achieve or approximate the functional benefits of my technology. > Bye > Michael Peter Olcott schrieb: > My method processes screen pixels, it does not need to understand the internals > of anything. I am trying to determine is the extent that competitors could use > alternative methods to achieve or approximate the functional benefits of my > technology. I don't see any other way to achieve this than processing pixels in some way - at least for the general case. BTW: pixels and screenshots can be obtained by java.awt.Robot. If one is happy to work with MS Windows controls, I could imagine the use of the Windows function WindowFromPoint to obtain a handle to the window or the use of a system hook to monitor window messages. But this is by far off topic and since I'm not really at home in this subject, I won't/can't deepen it. Bye Michael > Peter Olcott schrieb: >> My method processes screen pixels, it does not need to understand the [quoted text clipped - 13 lines] > But this is by far off topic and since I'm not really at home in this subject, > I won't/can't deepen it. There was an in depth discussion of this on another newsgroup that I carefully studied. There were problems with this approach for the general case too. It seems that there are many cases the make this method untenable. Here is the link to that discussion: http://groups.google.com/group/microsoft.public.vc.mfc/browse_thread/thread/32f6 ea916eb799d8/74db496855f60a0f?#74db496855f60a0f Hopefully I now have a product with market potential after 30,000 hours nineteen years, and most of my life savings. > Bye > Michael > Someone told me that Java always makes all of its graphical user interface > controls from scratch, and never implements its controls as Microsoft Windows > controls, is this always true, even for applets that run inside of Internet > Explorer? You get to pick whether to use native controls (AWT) or light-weight controls (Swing). Both of these libraries come with J2SE out of the box. You can alternatively download SWT, which uses a combination of the two techniques. Is there a reason you need to know this, or are you just assuming there will be a significant performance penalty for drawing components "from scratch?" >> Someone told me that Java always makes all of its graphical user interface >> controls from scratch, and never implements its controls as Microsoft Windows [quoted text clipped - 7 lines] > Is there a reason you need to know this, or are you just assuming there will > be a significant performance penalty for drawing components "from scratch?" There is a reason that I need to know this. I don't assume anything. There would be no reason why drawing a component from scratch would be required to be inherently slower. How popular is Swing and SWT relative to AWT? Which of these are used for web applets? >>> Someone told me that Java always makes all of its graphical user interface >>> controls from scratch, and never implements its controls as Microsoft Windows [quoted text clipped - 8 lines] > > There is a reason that I need to know this. Great, but could you be more specific? > I don't assume anything. There would > be no reason why drawing a component from scratch would be required to be > inherently slower. How popular is Swing and SWT relative to AWT? Which of these > are used for web applets? Swing is probably the most popular. Applets can be either AWT or Swing. You seem to have some confusion about what a GUI toolkit actually is. It's not a protocol that you use to interface one program to another; it's a way of interfacing with the user. If you're going to try to make your GUI look like somebody else's GUI, you should definitely choose Swing, which gives you the most control. >>>> Someone told me that Java always makes all of its graphical user interface >>>> controls from scratch, and never implements its controls as Microsoft [quoted text clipped - 23 lines] > somebody else's GUI, you should definitely choose Swing, which gives you the > most control. I have invented a way for one application to interface with any other application. I wanted to see how difficult it would be for competing products to duplicate the functional benefits of my technology. Thanks to Java Swing technology it looks like alternatives to my technology would be too difficult to implement, thus providing my technology with truly unique functional benefits. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.