Using a como file requires effort to wrap the application or processes just for this tiny function. It requires that you know something about what’s going to run so that you can start the como. Easier than that, you can just set the prompt in common and always set back to the latest prompt after some other process changes it. But again, this doesn’t allow a program to clean up after itself and to reset the prompt to whatever it was before. Well, I have a solution to that now – now I just need to write Part 2 of this blog to explain why I’m not going to publish this or many other solutions.

Best to you, Louie, and thanks for visiting my blog!

The problem has always been that people look at Nebula marketing, see the BlueFinity name, then contact them directly for info. Then they call here to ask for assistance installing software that they’ve already obtained from BlueFinity. At that point we can’t help. The only way this works is when the prospect calls Nebula first, or if they call BlueFinity to ask questions but state up-front that they were referred by Nebula R&D and that they’d like to work with us. That rarely happens. People don’t understand the relationships, they just want to know about the software. We understand these dynamics and just work with it as best we can.

As for “running for office”, I wish this community had positions for market leaders. Sure, I’d run … whatsit pay? Seriously, if any of these MV DBMS companies, or even Spectrum, had a position for “MultiValue Evangelist”, I’d probably apply. But they don’t – and here we are.

It would be a neat feature if you could point to a file item and read it “as-list” so that you could readnext through it with a cursor to the file space rather than pulling the whole thing into workspace, thus duplicating static data. Maybe this is the way it works internally, I dunno. I’m no engineer but since I’m the only person talking about this sort of thing in public I’ll share what I believe is accurate until someone corrects me.

About jBase, Jim Idle recently commented on this topic here:
http://groups.google.com/group/jBASE/browse_frm/thread/fc5767b575e9bb0c

tony, thanks for all your insights and the passion you have for the mv community. would you be averse to me nominating you for governor of MV?

danny

Regardless of where your “list” is held, in a variable or in frame space, won’t you still have to “SID” through the list?

In the “Factors for Consideration” heading, “This has less to do with a number of attributes and more to do with volume of data, or the LEN() of the variable containing the dynamic array.” strikes me as the meat of the matter. What’s not clear to me is determining that threshold in a general sense. I guess what I’m driving at is, when you are coding at some point you are going to have to say, “Hmmm, the volume of data I’m going to typically deal with here is {some value} and that crosses (or doesn’t cross) a certain threshold and because of that I’m going to process this list as a “LARGE” list.

In jBase, by default, does it really maintain a pointer in a dynamic list as you iterate through it or do you have to use the “REMOVE” command? I worked in the jBase environment a number years before stumbling into D3 and don’t recall that jBase was “kind enough” to maintain that pointer.

As always, thank you for your thorough response/s.

Danny

However when you’re exchanging data among trading partners, XML and related XSD documents are still the standard. You can also serialize documents and spreadsheets to XML as defined by schema, not JSON. And schema like DocBook are commonly used to exchange documents across the internet when people have no idea what software will be used to process it or how the data will be used. You also can’t do transformations on JSON with XSLT or parse through it with XPath or XQuery.

In short, JSON has its place, and I may blog about that too in relation to MV, but I don’t think we’re going to outgrow XML anytime in the next few decades.

thanks for directing me here. seriously, you unequivocally rock!

danny

Sometimes customers don’t want to see a mockup because they don’t perceive it as real work or something they don’t want to pay for. They want you to show them something they can actually use. Look at the customer’s face when you show them a mockup and the difference between that and a prototype they can play with. Sometimes it doesn’t matter how well you explain it or how right you are; they know they are the customer and will demand what they want. Sometimes a mockup is good and has real value, but other times, it can be perceived as a theoretical idea and won’t be applicable.

 Joe

About .NET … in the many years that I’ve been doing this thick/thin development I’ve been exposed to a lot of technologies. It’s impossible not to form preferences based on a personal sense of comfort, or to make decisions based on marketability. In short, I personally believe the .NET technologies (including Mono)  gives me the most flexibility, the best overall results, and solid commercial value for now and the future. I could go with passion and use (just an example) Perl, but all indications tell me that’s dead. I could go for "popular" but I can count on one hand how many times I’ve been asked for a Java solution in the MV market. I could go LAMP but the tools are just too primitive.

So I’m not biased toward .NET because of any particular affinity for Microsoft, it’s just been consistently a good solution – and as you say, you know I’ve looked at almost all of the others. I’m not shy about writing about non-.NET tech here. In fact my ongoing mantra is that we should always do our research for whatever might be (subjectively) "better". So I try to keep up with my research and I try to present my findings here for our colleagues.

I’m hesitent to do in-depth material on something like Ruby because, frankly, I don’t know anything about it. So I’ll leave such reviews to others with a clue – and I’ll be happy to link to material written by others if it seems of interest to the MV community. But I’m doing more work with "JACXX" stuff these days so I may write some material, for example, focused on JavaScript integration with MV.

And as long as your notes about Winnix are related to the content I have no problem with you mentioning your fine product.

Regards
T

Not to complicate the message but mv.NET is the same – one tool for many many applications, no need to put 10 different tools into your kit to solve 10 different problems, and that’s one of the reasons why I like it.

I would like you consider a blog another blog just on thick-clients. About Browser User Interface I think the easy solution is Visual Web Gui (www.visualwebgui.com). You can write a web application as you as if you are developing a Win Form based application.

Marcos Alonso Vega

http://www.adobe.com/devnet/devices/index.html?navID=gettingstarted

http://www.readwriteweb.com/archives/flash_10_for_mobile_devices.php
Related: http://arstechnica.com/software/news/2008/11/adobe-to-close-desktop-mobile-flash-player-gap-with-arm-port.ars Note these mention AIR for mobile as well.

http://www.techcrunch.com/2008/03/17/microsoft-adopts-flash-lite-for-windows-mobile-as-a-stopgap-measure/

http://www.linuxdevices.com/news/NS5010205574.html