For the mobile stuff:

Post #52,350 by tuberculosis 9/19/02 12:57:10 PM Reply	For the mobile stuff: Your hardware is going to be too underpowered to run your app - so you need a light client interface - wap or web browser based custom for the small screen size. If I had carte blanche to pick a new dev environment, I'd go download a copy of VisualWorks from cincom.com and get going. It'll run on PC's, Windows, Macs, Unix boxes, whatever and you can build both web interfaces and GUIs on top of the same business logic. That's my suggestion. The download is free - can't hurt to try it. I am out of the country for the duration of the Bush administration. Please leave a message and I'll get back to you when democracy returns.
Post #52,359 by Arkadiy 9/19/02 1:16:46 PM Reply	They have just released VisualWorks 7 Refactoring browser. Finally! I'll report my impressions here shortly. We have only 2 things to worry about: That things will never get back to normal, and that they already have.
Post #52,504 by Arkadiy 9/20/02 1:49:40 PM Reply	VisualWorks 7 Major, major win! I needed to do some major refactoring on that little game I was writing. Doing it with 5.x was so hard, I gave up. After an evening of tinkering with VW7, I can say the process became a pleasure. That browser they used needed a major facelift! We have only 2 things to worry about: That things will never get back to normal, and that they already have.
Post #52,381 by tseliot 9/19/02 4:54:55 PM Reply	Hey, yeah--ezboard uses it why not us? :D /ducking and running Many fears are born of stupidity and ignorance - Which you should be feeding with rumour and generalisation. BOfH, 2002 "Episode" 10
Post #52,445 by tuberculosis 9/20/02 6:24:34 AM Reply	A FORTRAN programmer can write FORTRAN code in any language EZBoard was more about management issues. I know, you're joking, but not everybody can see that. I am out of the country for the duration of the Bush administration. Please leave a message and I'll get back to you when democracy returns.
Post #52,446 by wharris2 9/20/02 6:59:13 AM Reply	Damn, that's pretty deep! a C programmer can write C in fortran or pascal or.... a C++ programmer can wite C++ in delphi a Pascal programmer can write Pscal in C++ or Java An XXX programmer can write XXX in yyyyyyy. The lawyers would mostly rather be what they are than get out of the way even if the cost was Hammerfall. - Jerry Pournelle
Post #52,447 by CRConrad 9/20/02 8:29:14 AM Reply	About that second line, I have a couple of suggestions... Da Beard (but not any more, we hear? Sis got over the heart attack yet?) writes: a C++ programmer can wite C++ in delphi 1: Yeah, sure -- just use short and cryptic names, and mess up your inheritance structure as much as possible! a C++ programmer can wite C++ in delphi 2: Of course he could -- but why not just use C++ Builder? :-) Christian R. Conrad Microsoft is a true reflection of Bill Gates' personality - the sleaziest, most unethical, ugliest little rat's ass the world has seen unto this time. -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=42971\|Andrew Grygus]
Post #52,466 by neelk 9/20/02 10:55:08 AM Reply	Re: Damn, that's pretty deep! An XXX programmer can write XXX in yyyyyyy. That's not always true. Eg, you can't write Lisp in C, because it's strictly more expressive than C -- it would be easier to implement a Lisp in C, and then use that.
Post #52,686 by ben_tilly 9/22/02 5:07:36 PM Reply	Partially disagree A Lisp programmer working in C might feel the constraints of the language. But their style would still show the Lisp influence, and they would be more likely to, for instance, take a heavily recursive solution or reach for pointers to functions than a person raised on C would. They just conceive of things differently. However it is easier to program like you are in another language when all of that other language's features are supported in the one that you have. Cheers, Ben "Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly." - [link\|http://www.nationalinterest.org/issues/58/Mead.html\|Walter Mead]
Post #52,473 by tuberculosis 9/20/02 11:07:32 AM Reply	Left out the qualification "An XXX programmer can write XXX in yyyyyyy." You need to add "where XXX is more primitive than yyyyyyyy". I am out of the country for the duration of the Bush administration. Please leave a message and I'll get back to you when democracy returns.
Post #52,450 by admin 9/20/02 8:59:28 AM Reply	Yep I worked with an economist who was taught FORTRAN in school, and self-taught C. His C had lots and lots of arrays and numbered variables. A few main routines. Single depth structs, etc. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #52,966 by static 9/24/02 7:06:49 AM Reply	Likewise. I once knew a guy who programmed everything like it was COBOL. I happened to see the effect in QuickBASIC, but I can imagine the effect in something like C... Wade. "Ah. One of the difficult questions."
Post #52,830 by deSitter 9/23/02 11:00:19 AM Reply	New dev idiom Well, not new, but maturing - PDF forms with Adobe Javascript as the scripting language - sort of "web without web" and all the display/printing is handled at the level of Postscript. I'm doing an entire company this way and the users are raving about it for ease of use. The stuff that shows up onscreen is exactly what they are used to filling out by hand. It takes only a few hours to add a new form and make it interact with existing ones. Each form has an associated workgroup DB that gets replicated periodically or on demand. So, the forms have a life of their own, just like in real life. And you can build from the outside in, which is very natural. (PS - Adobe Javascript is not your father's HTML forms world.) -drl
Post #53,784 by tablizer 9/29/02 1:47:05 AM Reply	Avoid web-based (* wap or web browser based custom for the small screen size. *) Nahw! You want coordinate-based control of the screen. Flow-based (nested) layout management of widgets goes down-hill really fast for non-trivial UI's. Others may disagree, but that is my .02. ________________ oop.ismad.com
Post #53,969 by deSitter 9/30/02 12:46:35 PM Reply	Re: Avoid web-based Agreed, but disgreed. Avoid web-based, use Acrobat for forms. It's killer-diller! And it's completely transparent across anything that can run Acrobat (Reader). It's close to realizing my dream of HTML/PDF unification. -drl
Post #54,153 by boxley 10/1/02 12:25:23 AM Reply	okay now I am totally confused html is a language that allows input fields across a lot of platforms. The input can be used to access a lot of legacy and non legacy type data which is then displayed back to the user in a co-herent fashion. It is called stove-piping. What the heck is wrong with that? thanx, bill will work for cash and other incentives [link\|http://home.tampabay.rr.com/boxley/resume/Resume.html\|skill set] qui mori didicit servire dedidicit
Post #55,000 by tablizer 10/5/02 12:43:18 AM Reply	What, character Lynx? ________________ oop.ismad.com
Post #55,033 by pwhysall 10/5/02 3:37:40 AM Reply	Yes. Peter [link\|http://www.debian.org\|Shill For Hire] [link\|http://www.kuro5hin.org\|There is no K5 Cabal] [link\|http://guildenstern.dyndns.org\|Blog]
Post #59,582 by tablizer 10/25/02 11:07:06 PM Reply	Fsck Lynx. Don't hold the other 99.9% hostage ________________ oop.ismad.com
Post #54,158 by altmann 10/1/02 2:09:45 AM Reply	I got your coordinates right here <input type="text" style="position: absolute; left: 100px; top: 60px; width:100px; height:20px" /> -- Chris Altmann
Post #55,002 by tablizer 10/5/02 12:50:23 AM 10/5/02 12:51:34 AM Reply	re: I got your coordinates right here That is a start, but there is still the whole event-handling and "session persistence/redraw" issue. Rather than rekindle that battle all over again, here are links to my side of the story: [link\|http://geocities.com/tablizer/webstif.htm\|[link\|http://geocities.com/tablizer/webstif.htm\|http://geocities.co.../webstif.htm]] and [link\|http://geocities.com/tablizer/scghist.htm\| [link\|http://geocities.com/tablizer/scghist.htm\|http://geocities.co.../scghist.htm]] ________________ oop.ismad.com Edited by tablizer Oct. 5, 2002, 12:51:34 AM EDT Expand All History
Post #55,032 by altmann 10/5/02 3:31:39 AM Reply	re: I got your coordinates right here There is a fourth approach: store the view state in hidden, compressed HTML form fields to be re-loaded into RAM on the next pass. The problem with this approach is that we cannot easily "interrupt" one form or screen with another, and then come back. Therefore, I will not discuss it any further. Too bad you dismiss this approach because up until this point you were describing the ASP.NET model almost exactly. Yes I realize your objections to having to pass viewstate back and forth, but the meat of your article was how to make the best of the web situation. If you are worried about interrupting a form, you could open the new form in a separate window (like most traditional VB apps would), then use client side scripting to trigger a refresh in the original form if needed. Some people seem to also be storing the (hidden form field) viewstate in a (server side) session variable for later use. I suppose you could store it in a table too :) PS. Have you ever looked at XUL from the Mozilla project? Not what you looking for either (It also uses JS+DOM, but at a higher level of GUI abstraction), but it could be a platform on which to build your ideas. You could make your own SCGUIzed Mozilla based browser. -- Chris Altmann
Post #55,083 by tablizer 10/5/02 6:18:47 PM Reply	why on the client? If you are worried about interrupting a form, you could open the new form in a separate window (like most traditional VB apps would), then use client side scripting to trigger a refresh.... If you are going to depend on client-side scripting, which is often buggy, version-sensative, and inconsistent, then you might as well go with an applet-type approach. That would be better than JavaScript+DOM imo if it was not so bloated. JavaScript+DOM is a "medium client", not fat, but medium; plus it is a sloppy addon to the HTML model instead of built for GUI's up front. Better to just byte the bullet and store the "state" or "UI image" on the server rather than the client IMO. It makes things conceptually far simpler. PS. Have you ever looked at XUL from the Mozilla project? I may have. It sounds familiar, but from a while ago. I have not been playing with SCGUI much lately. B-to-B stuff just needs better, simpler HTTP-friendly GUI protocols. Nobody seems to want to directly solve this, living with kludgey hackey approaches instead and worrying about performance instead of programmer productivity, which is usually the more important thing for B-to-B. They assume everybody is ebay. Thanx for the feedback, -T- ________________ oop.ismad.com

Welcome to IWETHEY!