Printable View
That's great if you have access to the database. I can also imagine it keeps things nice and tidy with a single 'go to' place when business needs change.Quote:
Originally Posted by szlamany
Unfortunately, some of us work in an IT world where they think that the database is 'theirs' and no one should meddle with it - the only reason it exists is to support the business process. Mordac, the preventer of information services would be proud.
@tg - very nice - that is DRY'er then mine.
I live in the nuts and bolts of my meta data. I've considered that I could abstract away further - just no time.
That is sad - I'm a DB junkie - they can't take it away from me!!Quote:
Originally Posted by SJWhiteley
I use agile development methods - I need to do 50% of the db, 50% of the UI - show the client - THEY ARE going to ask for CHANGES - do another 20% - show more - another 20% - never done - that's what maintenance is for!
Not sure how a VB6 design time database connection would make that any better (as Dil suggested all true VB6er's must do).
The edit form is slightly complicated, but only in that it has two stored procedures - the load and the update....
It looks very clsoe to teh add form:
Now we have a table, we can add records and edit them.Code:<EditFormSpec
Id="{guid value}"
Name="Student edit form"
Description="Edits a student record to the system."
Developer="TG"
>
<SPDataForm>
<LoadImplementation SProc="USP_STUDENT_EDITLOAD">
<CreateProcedure>
<![CDATA[
create procedure dbo.USP_STUDENT_EDITLOAD
(
@ID uniqueidentifier,
@DATALOADED bit = 0 output,
@TSLONG bigint = 0 output,
@STUDENTID nvarchar(9) = null output,
@FNAME nvarchar(50) = null output,
@LNAME nvarchar(100) = null output,
{more fields as needed}
)
as
select
@LOADED = 1,
@TSLONG = TSLONG,
@FNAME = FNAME,
@LNAME = LNAME,
@STUDENTID = STUDENTID,
...
FROM dbo.STUDENTS
where ID = @ID
]]>
</CreateProcedureSQL>
</LoadImplementation>
<SaveImplementation SPName="USP_STUDENT_EDITSAVE">
<CreateProcedureSQL>
<![CDATA[
create procedure dbo.USP_STUDENT_EDITSAVE
(
@ID uniqueidentifier,
@USERID uniqueidentifier = null,
@STUDENTID nvarchar(9),
@FNAME nvarchar(50),
@LNAME nvarchar(100)
)
as
update dbo.STUDENTS
set
STUDENTID = @STUDENTID,
FNAME = @FNAME,
LNAME = @LNAME,
CHANGEDBY = @USERID,
DATECHANGED = getdate()
where ID = @ID
]]>
</CreateProcedureSQL>
</SaveImplementation>
</SPDataForm>
<FormFields>
<FormField FieldID="FNAME" Caption="First name" DataType="string" MaxLength="50" />
<FormField FieldID="LNAME" Caption="Last name" DataType="string" MaxLength="100" Required="true" />
<FormField FieldID="STUDENTID" Caption="ID number" DataType="string" MaxLength="9" Required="true" />
</FormFields>
</EditFormSpec>
Next step is to create the list of students.
that belongs to a data list:
Boom... we now have a list...Code:
<DataListspec
Id="{guid value}"
Name="Student listing"
Description="Lists all students in the system."
Developer="TG"
>
<SPDataList SPName="USP_STUDENT_DATALIST">
<CreateProcedureSQL>
<![CDATA[
create procedure dbo.USP_STUDENT_DATALIST
as
set nocount on;
select
ID,
STUDENTID,
FNAME,
LNAME,
....
from dbo.STUDENTS
]]>
</CreateProcedureSQL>
</SPDataList>
<!-- define the output fields in the list -->
<Output>
<OutputFields>
<OutputField FieldID="ID" Caption="ID" DataType="Guid" IsHidden="true" />
<OutputField FieldID="STUDENTID" Caption="Student number" DataType="String" />
<OutputField FieldID="FNAME" Caption="First name" DataType="String" />
<OutputField FieldID="LNAME" Caption="Last name" DataType="String" />
</OutputFields>
</Output>
</DataListSpec>
Now we create a page that brings it all together:
Now we have a fully functional student CRUD operation well, CRU ... I didn't include the delete operations.Code:
<PageSpec
Id="{guid value}"
Name="Students"
Description="Page for maintaining students"
Developer="TG"
>
<Tabs>
<Tab ID="{guid}" Caption="Student list">
<Sections>
<Section ID="{guid}" Caption="Students">
<DataList ID="{guid form the data list spec}" >
<Actions>
<Action ID="{guid}" Caption="Add" ImageKey="res:AddNew">
<ShowAddForm DataFormID="{guid form the add form spec}">
<PostAction>
<RefreshSection />
</PostAction>
</ShowAddForm>
</Action>
<Action ID="{guid}" Caption="Edit" ImageKey="res:edit">
<ShowDataForm DataFormID="{guid form the edit form spec}">
<Context><SectionField>ID</SectionField></Context>
<PostAction>
<RefreshSection />
</PostAction>
</ShowAddForm>
</Action>
</Actions>
</DataList>
</Section>
</Sections>
</Tab>
</Tabs>
</PageSpec>
But form all that the platform can built a completely interactive web-based form that allows the suer to see a list, select a student and edit them. Or add a new student.
This obviously shows just a basic, simplistic capability... there's tons more optional stuff - the list can be filtered - the list can auto expand when a student is selected to show student details not in the list (like address, class schedule, etc) and we can even render a field (or two or more) as hyper links that go to another page - so Student ID could be a hyperlink that then goes to a Student Details page.
and in any of the sprocs, they can be as simple or as complicated as needed. I've gone the simple route here just to show the concept. and since the specs are XML-based, they all have schemas in our SDK, which then speeds things up withe intellisense and letting you know what's possible and what isn't (like in the edit form, the load must come before the save sproc.
One of the other powerful things I didn't show was that on these forms, we can link them to UIModel components - this gives us the server side ability to perform logic if needed... as well as creates an HTML file if we need to control the form layout specifically (like putting Fname and LName on the same line instead of in a vertical format). the UIModel then gives me the same capabilities as if I was on a winform client side... so I can enable, disable fields, perform business logic, etc... and it all runs on the server. the platform takes care of the js wiring to make the service calls when it needs to.
-tg
@tg - very nice stuff.
fortunately our clients are usually... well, IT isn't often their priority - they're non-profits, so we don't usually run into that, but then again, the fact that thigns are in the database the way they are in our case, they know full well that's how it works.Quote:
Originally Posted by SJWhiteley
Ever since I cut my teeth on .NEt, I'd been thinking that it would be nice to build custom screens using XML meta data... at the time I wasn't in a place that was receptive to making the investment to making such a change... then I moved on... still, I mulled it over... then I got where I am now... and they had already figured it out! And it even started off as client-rich winforms app... the web-based client didn't come around until a few years ago. Even then, it wasn't until 2012 that we went full tilt web-based and no longer support the winforms version of the product.Quote:
Originally Posted by szlamany
-tg
Oh... and the page spec also has an AlterPage section... have a client that wants to make Last Name clickable instead of the Student ID? Create a new datalist, then alter page, swaping out one data list for the otehr (<ReplaceDataList OldDataListId=".." NewDataListID=".." /> -- it's that simple).Quote:
Originally Posted by szlamany
-tg
Check this out - I can call up a FORMULA for the GRID - that I store in the DATABASE.
I then use this formula as numbers are entered so that balance fields pan out.
Doing this in JavaScript is a piece of cake - code injection is just as easy as DOM manipulation.
The ParseMoney and ParseCurrency functions are my own - JS doesn't have a currency datatype
agile development:Quote:
Originally Posted by szlamany
Euphemism.
Repeatedly throwing code at the wall until it sort of sticks. When it slides off the wall again blame the user, then throw some more.
Bonus: though nothing ever gets completed and the product at any time is usually a Rube Goldberg Machine and is impossible to maintain... you can use semi-skilled coders and the cabal of involved users are supportive because they "got to be involved instead of doing my boring real job."
A win for those involved and a huge loss for the organization.
Sort of the Monty Python's Upper-Class Twit Olympics for programmers.
Right... like the waterfall method is any better. No thanks.
That said, agile can only really work if you get buy in from all the stakeholders at all levels... which rarely happens... when ends up with stake holders, and pitch fork holders, and torches and villagers storming the castle walls.
-tg
From all those posts I just put up - you picked up on that?Quote:
Originally Posted by dilettante
Software lives - my apps are alive - people want more and more changes always.
Call it phase 2 or whatever you want.
Regardless - the architecture of the solution I offer my clients invites changes which lines right up with their needs and my cash flow. Hat trick!
I'm just kind of ignoring dilettante at the moment. We've butted heads in the past, and I was needlessly mean to VB6 back then. I feel like now I can learn a lot from a VB6 developer, but it looks like he's still pretty firm that nothing relevant's happened in software engineering since 1999. I'm really struggling to not say some mean things about that, but it's just not productive.
That DB UI system's pretty slick, by the way! I'm going to keep it in mind if I end up falling into that kind of job.
I can't think of anyplace I said anything of the kind, though I'll admit to saying things better summed up as "change isn't necessarily progress."
There is no waterfall method. That's a straw man used by people trying to market patent-medicine methodologies and people trying to excuse undisciplined development practices. Sadly some organizations actually have adopted a weird, faux "waterfall method" though.Quote:
Originally Posted by techgnome
A Waterfall Systems Development Methodology … Seriously?
It all comes down to managing expectations - feature-creep is a by-product of unmanaged expectations. Which leads to deadlines being missed and no income left to fund the final efforts.
Which was the whole point of the past dozen or so threads - how to be RAD.
Does anyone have a methodology that they feel makes them more RAD? Regardless of VB6 - just in general. We can bring it back to VB6 after we get some more info.
Wouldn't a "RAD" thread be more productive? This one has wandered all over the place.
I believe you started all this current off-trackness in post #820 in response to sittenspyne's post #819.
What would you rather we talked about, sir?
I'd sure like some opinions on RAD. I never read a lot about either RAD or agile processes formally, but absorbed a lot of agile while reading about testable designs.
From the scant resources I found, RAD:
- Emphasizes stakeholder involvement as early as possible.
- Values fast prototyping and iterations over up-front design.
- Handles uncertainty by presenting best-guess, low-infrastructure prototypes and soliciting feedback.
- Refactors prototypes towards better architectures when uncertainty is low.
That's... hard for me to distinguish from "agile". Scrum just bolts on an estimation style to those same concerns. TDD asserts that the best way to prototype is to start with tests as a specification for known required behaviors. Those all feel like they could nestle snugly into the high-level overview of RAD. Maybe, in this sense, "agile" is a container for patterns, and RAD is one agile pattern. Sort of like how Presentation Model compares to MVC or MVVM.
But it's hard to talk about RAD when I'm ignorant of what gets you the gold-stamp certificate from a paper mill. I know what kind of things make a "certified TDD" shop and which of those you throw out the window the moment you get your fancy sticker. So what's the skinny on RAD? What's the book say you do vs. what real developers do? What's it do well that other processes don't? What's it do badly that other processes do? If VB6 is a "RAD language" and VB .NET is not, what's the distinguishing factors?
For me RAD wasn't so much a development paradigm as a language capability. VB, with it's GUI designers, data wizards etc. let you throw together Apps rapidly so it could call itself a RAD tool. When people talked about RAD development I think it was largely double speak for "we chuck something basic together and then keep changing it until it meets the customer's need".
I think Agile is subtly different in that it tried to nail down some good design principles from the start. TDD (later BDD), Regular SCRUMs, Time estimates etc. are all there to try and add some order to the chaos of iterative development. Sadly, most places that say they're doing Agile development don't actually adopt any of those practices and they are, in truth, doing exactly the same as we used to call RAD.
I don't think this is necessarily a bad thing though. Hacking works. It gets product out the door and does so quicker than a front heavy water fall approach does. While many would like to deny it, the best development approach to many projects is probably to dive right in and work until it's done.
To me the best advances over the last couple of decades aren't that we decided to rebrand RAD as Agile but rather that we've advanced the design patterns we use at a small level. We've learned how to get our design to police our work and how to make our code both testable and flexible. We learned how to structure things in a way to allow for refactoring and we learned to refactor safely through automated testing. I don't see Agile as fundamentally different from RAD, we just got better at it.
I have a client that has auditors that watch the development dollars for ongoing projects.
Current contract I have with them has 3 Sprints (covering 52.5, 23.8 and 23.8 percent of the project). Total project was laid out over 275 days so we just took those 3 percentages to mark when each sprint was done.
Development tasks are each brought further along as each sprint completes. Issues such as: you want to discuss all your output/export requirements before ending Sprint 2 so that the final Sprint has all that knowledge going into it. Some business logic SPROCS (like close a contribution receipt to cash) are only running in query development windows. Lots of final wiring of all that in the UI in final sprint.
We are currently stalled in Sprint 3 due to an uncooperative third party software house.
Nice thing is there is enough dollars left in the budget for me to come back and bring it to fruition.
Basically it is all about the dollars - you have to have cash left for the whole game regardless of how hard the end goal is. No good software gets developed in that situation.
I'd like to talk about the thread's topic: "a new VB6."Quote:
Originally Posted by szlamany
And accept the premise that Microsoft won't ever produce one, accept the things Microsoft got right in creating the VS tools for .Net languages, and that .Net languages are already there for anyone who wants to use them...
... but that some people don't want to, and would prefer some alternative.
There could be many motivations for wanting an alternative, but alternatives abound already. So then the question becomes "What do these people want?"
Different people will have different laundry-lists of "wants" but most of these appeal to small groups of people with special needs. For a VB6 successor aside from VB.Net (which is there for the taking) popularity would probably be key. Without broad adoption such an alternative just becomes another one among so many, none of which ever became wildly popular.
Popular means lots of people would use it, and they probably are not going to be advanced users so making it as "approachable" as possible would probably be key. Most of these people are going to be making fairly simple programs to solve simple problems for themselves. They are going to be self-taught. So it probably needs to be possible to get useful results knowing a small fraction of what the language and its tools offer. And it probably needs to be easy to install, most likely without admin rights because a lot of office workers will be using it for simple "stealth IT" sorts of things... like it or not.
This could be a .Net language based on VBA syntax supporting only WinForms and that might make a lot of people happy. Or it might be actual VBA bundled up with one of the Office Forms libraries and the VBA IDE able to "compile" to MS Access MDE-like executables without the Access Runtime. Or it might be something else entirely like a JavaScript-centric toolchain that can create desktop applications.
I focus on these users because that's probably where the action is, i.e. where the lack is being felt most strongly.
Ha you're lucky dilettante, I just chugged a margarita thanks to an excruciatingly painful QA meeting so I'm feeling pretty good and agreeable right now!I understand this, and really my only negative response is I'm not sure if that user represents a good revenue stream for a budding new language. It's definitely a niche, but not in the sense of "small cottage industry". I mean it in the sense of "group of people with specific needs that will spend a LOT of money to get something that scratches their itch." Ignoring them is definitely stupid. Catering to them? I'll let someone else put wagers down first.Quote:
Originally Posted by dilettante
Add to your list of requirements that this language should run on some form of tablet, with at least some token iOS/Android functionality, and I'll buy the next round.
I think the coolest dang thing about VB6 that no "modern" professional admits is that as a swiss army knife it totally delivered. It's got a Perl-like "make easy things easy, and hard things possible" mentality, without the "Learn this one neat trick that every other developer hates" mentality in most cases. I can be a total Mort and mash buttons like a neanderthal in some wizard and get something that works, that's still amazing in 2015 so getting it done in 199x was like Microsoft producing the Ark of the Covenant. But then, if by some miracle, Mort reads a couple of API books by accident, he suddenly has access to a whole new world like he's Aladdin. She wants to write apps without the wizards, and VB6 has her back despite the sudden shift in gender. And then if, somehow, that developer spends some free time reading COM documentation and doesn't die, VB6 is still there, with a few shady tricks that are pretty easy to internalize. Now we're not dealing with Mort. We're dealing with someone that can finish a project in half the time a C developer can. We could bicker about "bad architecture" but let's face it, architecture's a hard problem and the reason we've got so many languages is we're desperately trying to find out what works, and haven't had enough time to settle on one. If your software's only problem is you're a little worried about architecture you're probably fine.
That's why I couldn't abide Lightswitch. It looked cool, and I think it's showed up in Swift's "playgrounds", but I was really turned off by the fact that at some level of complexity you had to convert it to a "real" .NET language. VB6 never needed to be transformed into C, it showed up and asserted with bravado that C would be dead in its wake. If people had half a brain, that should've happened in terms of Windows clients. I think a key mistake there is assuming the enterprise market has half a brain. MAYBE collectively, but definitely not individually.
Despite my career being in C#, I've always in my heart seen it as "the VB .NET that C developers could tolerate". Except for the VB lambda syntax. That's just horrid.
Anyway, yeah. What you said, but let consumers write their own iOS/Android apps with it. App Wizards a must for that respect. This idea will topple half the App Store market, and I say good riddance. $4.99 a copy for half a year's work? That's a pittance.
I'd had some hope for Mozilla XUL though even they've abandoned it.
Then Chrome Packaged Apps looked pretty interesting, and that has a "mobile story" as well.
These seem to come in two flavors: packaged and... not packaged. Or perhaps "not packaged" are just "Chrome Apps" that nobody ran the packager against? I haven't followed this through its development and evolution so I'm a but fuzzy there, though I had the idea there are three things: Chrome Apps, Chrome Packaged Apps, and Chrome Packaged Apps that have not yet been packaged for distribution but will run locally. The main divide being online web apps vs. offline local apps?
In other words Chrome Packaged Apps are sorta kinda like Windows HTAs.
Old but as far as I know not obsolete:
Chrome Packaged Apps - Programming Model video 2:17
Chrome Packaged Apps - A quick overview video 2:18
Basic Structure of a Chrome Packaged App video 12:16
It all looks good until you get to the gory details of course. First you have the twin horrors of JavaScript and the HTML5 DOM's 290 levels deep object hierarchy with long-long-long names for so many things. Then you have the tooling: text editors available that can colorize, auto-indent, and auto-complete... for you to bang out HTML, CSS, and script in the dark with.
Can you say not quite Visual Studio? I swear, if these guys saw the VB6 IDE in action they'd break down and cry at "the amazing future."
So that's been an option for some time. However I can see why adoption has been minimal outside the ChromeOS world despite the Chrome browser's (the only run-time infrastructure required) ubiquity today. The tooling is just far too 1985 and well... JavaScript.
Ahh, here's another:
Chrome Apps on Android and iOS video 5:22
I'm not a C# nor VB.NET developer, but that's exactly how I see it. And I strongly believe that it is true - their goal was to attract C and other developers to think they made a new language while in fact, it's just VB.NET under the mask. They've also tricked VB6 developers to think it's just an evolution of it while in fact, it's a whole new platform which is not producing native Windows applications nor has any other connections with Classic VB, except similar syntax.Quote:
Originally Posted by Sitten Spynne
I'm afraid I disagree on both points.Quote:
I'm not a C# nor VB.NET developer, but that's exactly how I see it. And I strongly believe that it is true - their goal was to attract C and other developers to think they made a new language while in fact, it's just VB.NET under the mask. They've also tricked VB6 developers to think it's just an evolution of it while in fact, it's a whole new platform which is not producing native Windows applications nor has any other connections with Classic VB, except similar syntax.
I think c# may have been "VB.Net that developers could tolerate" 10-15 years ago but the perception has moved on hugely since. C# seems widely respected in it's own right these days. The last company I worked for (GE) was developing AI engines to detect emergent faults on Aeroplanes - pretty serious stuff. Once upon a time they'd probably have chosen C but these days they chose C#. They also did work to optimise deep sea oil fields - C# again. There was also a whole bunch of Java in the mix and cross language communication was handled with thrift.
And I really don't think MS ever tried to trick anyone that VB.Net was anything other than a new platform. They were quite open about it and have been ever since. I understand that some folks weren't happy with that move but I don't think you can portray it as dishonest.
Whoa, hold on there.Quote:
I'm not a C# nor VB.NET developer, but that's exactly how I see it. And I strongly believe that it is true - their goal was to attract C and other developers to think they made a new language while in fact, it's just VB.NET under the mask. They've also tricked VB6 developers to think it's just an evolution of it while in fact, it's a whole new platform which is not producing native Windows applications nor has any other connections with Classic VB, except similar syntax.
So the Statement that C# was created to attract C style language developers to .Net is of course true.
To try and imply that C# is basically VB.Net is utterly utterly wrong and your confusing the language with the framework here.
What your ignoring is the fact the .Net framework support more languages than just VB.Net and C# that part of the point of it that you are not bound to one language, and those languages are wholly different.
Also the idea that MS tricked anyone with VB.Net is a complete fallacy also, and comes from the fact you don't like .Net.
That right there I think sums up the problems a lot of people have... they think that the framework is the language and the language is the framework when in fact that's not true. there's the BASIC lexicon nearly all of which is in the VB lexicon... and that's still there.... Dim statements... If Then (else/elseif) end If constructs... those are the VB syntax... but System.Io.Path.Exists... that's framework... that's not part of VB. That's just simply a library. I think that's also where people have problems with .NET, navigating the rich framework model.... it can be daunting with all the naespaces, classes, determing what's static, what needs to be instanciated, but eventually you learn. And if you can do it in VB, it's the same framework in C# ... so all you need to do is learn the differences in the syntax and you're mostly there.... System.Io.Path.Exists works the same in both.Quote:
confusing the language with the framework here.
-tg
Well, actually (the canonical engineer phrase!) their goal was to attract Java developers. If you were around during early .NET, there was a big race to convert every example Java application to .NET and advertise how much faster it ran on the .NET platform. I get the feeling C developers aren't impressed by much and don't jump fences often.Quote:
Originally Posted by MikiSoft
It's not even really VB .NET 'under the mask", it's IL. Because that's what VB .NET is under the mask. That's a little nitpicky, but in general you can say "C# and VB .NET can do the same things" and be almost right. There's a small list of frustrating places where they do not overlap, but most of those are syntax sugar rather than actual CLR features.
I haven't seen a tricked VB6 developer yet. Now, I also wonder if "not producing Native Windows applications" is a truthful statement at this point. WinRT is a .NET platform, and as of a couple of years ago MS's mandate is "WinRT support is mandatory for all new APIs." If I follow that dotted line, I could argue that ".NET is the native Windows platform" in a lot of ways. But that feels like something we could go in circles over.Quote:
They've also tricked VB6 developers to think it's just an evolution of it while in fact, it's a whole new platform which is not producing native Windows applications nor has any other connections with Classic VB, except similar syntax.
I'm reminded of a story I saw once about a person's trip to Paris. They spent a few weeks studying French beforehand, because they didn't want to be a total American Tourist. They sat at a restaurant and, with their dictionary, started to stumble their way through an order. The waiter smiled, and in English helped them with their order. 5 minutes later, at another table, the same waiter was dealing with another tourist. "DO. YOU. HAVE. ENGLISH. MENUS?" The lady subscribed to "loud, slow English is universal". The waiter? "Je ne parle pas anglais."Quote:
Originally Posted by techgnome
It takes 0 minutes to read a basic C# program, it's just curly braces and semicolons. It takes 10 minutes to learn about its method declaration syntax, event handler syntax, and a quick overview of its lambda syntax. That's C# in 10 minutes. Take the time to learn it, the people making fun of VB assume you never will. I get a little angry every time I see a post that contains, "I can't read C#". It's really just "write it for me", but the concept is strange. They're so similar, and they use the same libraries, so I've always felt if you can't comprehend even the expression lines of C# I have little confidence you have any grasp of VB.
"Don't want to" is precisely what makes people think poorly of VB devs.
nice story... and yeah, I cringe when I see that "but it's in C#" from posers. At every single interview I've been to since 2006 I've been asked about my VB.NET experience (which was minimal at first) - almost always followed by "What about C#?" My answer has been virtually the same every time: ".NET is .NET is .NET ... because both languages are built on top of the same framework, they differ only in their syntax. Once you know what those syntax differences are, it's not too difficult to switch from one to the other. While more efficient with VB, I can be productive with C#. Only thing that really slows me down is remembering to hit all those curly brackets."Quote:
Originally Posted by Sitten Spynne
While I've never been asked to write specifically in C#, I can if I need to... and at my current job, it's an option if I want to, even though it's not our shop standard.
-tg
Wow, another round of shout-singing in the dark.
I don't get all of this insecurity. If people choose not to use .Net languages that's their choice. I can see a few lines to correct an erroneous statement but this reaction is ridiculous. It also appears to account for almost all of this thread to date.
Careful, VB6 net is going to "get" you. Better crawl under the bed.
Ok, I went back and read post #1. I guess the entire thread was insane from the beginning and I realize I don't care about it after all.
I guess I forgot I was assuming some implied context.
A VB6 dev who says "I can't read C#" is making a fair argument, I don't expect them to have studied the .NET Framework. And I don't pitch C# examples at them, and in general don't hang out in the VB6 forum because I don't feel qualified to answer those questions. Unless someone specifically calls on me to provide some C# example in a VB6 forum. Which would be strange.
A VB .NET dev that says it, on the other hand, is saying that they're not up to the task of parsing lines like this representative of the esoteric, confusing C# syntax:
I can't think of a good analogous situation for VB6, there weren't any other languages I know of that use the runtime, and "I don't understand API" is sort of why people liked VB6 in the first place so it's not a good one.Code:var myForm = new Form1();
myForm.Show();
You're right though, post #1 is weird. I skipped to the end to see what was going on and found some people bickering about whether VB6 was OO enough to be a "real" language, or whether VB .NET being OO meant it was too complex. Then we wound our path through a lot of topics. I wonder how the lawsuit's going?
Well there's a little bit of the same thing in the (small) B4J community.
That language compiles to JVM bytecode (probably by preprocessing it into Java first), and programs often make use of Java libraries repackaged so the B4J IDE can accept them but... don't bring up Java literacy as useful there or be prepared for backlash.
The suggestion alone brings up all sorts of fears and a rabid defense against it arises immediately.
BTW: Cue the sad trombone ("wah-wahhhhhh").
Google Closing Packaged Apps
Summary: Chrome Packaged Apps (CPAs) are dead and gone. Now all you have are "Chrome Apps" (CAs) which are not the same thing at all.Quote:
The only option is to migrate to a Chrome app and Google has provided a guide to how to do it. This seems to be fairly easy. You have to update the manifest and set the Content Security Policy to something reasonable. Beyond that most of your existing code is reusable but you have to take account of a slightly more complex lifetime model and events.
What is really surprising is that after so very long it still seems to be difficult to implement a system for web apps that makes them the equal, or even nearly equal, to a native desktop app.
I suspect the problem was at least in part because a CPA had the ability to access local storage and devices. I'm not sure whether the concern was security or an undermining of Google Drive.
It's hard to tell with the browser app frameworks. It's a shame, because they could be really powerful and useful, but every time I've tried to take a look it's made my head spin.
Java just needs to die. Quietly. It's not even in the same league as VB6 and that has been trying (unsuccessfully) to go away. Get Java programmers to realize that their thinking 'outside the box' is really just playing in the dirt. Give them a real language and environment and they will (should) realize that they can'y program or design worth a damn. But then, I guess the proper programmers stuck with it, while the programmer wannabes moved to Java in the mistaken belief that it's 'portable' and therefore better than anything else.
And browser App frameworks are also a stupid idea - a nice experiment, but just ... no (but then, that's what Google was(?) all about, and have been very successful with the 1 in 10 apps/projects that are actually useful, or bring something to the table).
Java's going to be around forever, languages don't die when they're that widespread. And again with the "real programming languages" and "real programmers" stuff!
Until C# showed up, Java was the state-of-the-art in OO languages and it still technically implements a more "pure" approach to OO than C#. Java has a bad reputation for the similar reasons VB6 has a bad reputation:
- A lot of programmers don't really care to spend time learning how to write clean, maintainable code.
- A lot of projects don't have the budget or time to write clean, maintainable code.
- An overzealous application of OO techniques makes just as fabulous a mess as letting the above two situations happen within the VB6 IDE.
It's a cool language, but recently burdened by trying to do things differently than C# for competitive rather than technical reasons. The approach to generics looks like madness, and came far too late. As a result, its lambda support also took too long and has questionable merit. The "wannabes" end up in Java because it hits all of the high points of a viral language: it's free, it's powerful, it's C-like, it's cross-platform, there's 4,000,000 articles on how to do any task in it (some of them right), and PHBs feel like they know what it is and that it's "stood the test of time."
But really, cross-platform UI is a big deal. I used a Java-based tool for automating a browser game for a while, and that it was distributed as a .jar meant I could keep it in one Dropbox folder, with all my customization scripts and logs, and it just ran on Windows or Mac and I could play my game whenever I wanted wherever I wanted. I can't do that with C#. I can't do that with VB6. I can't really name a language besides Java that can produce a self-contained executable with a GUI on all platforms. Even having a bad implementation of that is better than having no implementation.
It will be interesting to see how the .Net Core cross platform stuff goes and if it takes off - http://venturebeat.com/2015/04/29/mi...mac-and-linux/Quote:
Unfortunately Java can't die. MS has, so far, done a terrible job of actually delivering on the cross-platform promise of .NET by refusing to spend money on anyone who wants to use .NET without a Windows license. That means, for the entire lifetime of .NET, if you needed to target Linux/Mac/embedded systems you were either at MS's mercy or using Java. It also got a very, very big boost from being the preferred API language for Android.
.Net Core is far from trivial or pointless, but it doesn't offer anything to most current .Net developers because it is a tiny subset of .Net technologies.
As Introducing .NET Core says:
So not only is it a subset of .Net as you know it, it's a fork of .Net as you know it and expected to diverge from the .Net you know. That's good news, since it means fewer breaking changes as time goes forward.Quote:
.NET Framework 4.6
The .NET Framework is still the platform of choice for building rich desktop applications and .NET Core doesn’t change that.
For Visual Studio 2015 our goal is to make sure that .NET Core is a pure subset of the .NET Framework. In other words, there wouldn’t be any feature gaps. After Visual Studio 2015 is released our expectation is that .NET Core will version faster than the .NET Framework. This means that there will be points in time where a feature will only be available on the .NET Core based platforms.
We’ll continue to release updates to .NET Framework. Our current thinking is that the release cadence will roughly be the same as today, which is about once a year. In these updates, we’ll bring the innovations that we made in .NET Core to the .NET Framework. We’ll not just blindly port all the feature work, though – it will be based on a cost-benefit analysis. As I pointed out, even additive changes to the .NET Framework can cause issues for existing applications. Our goal is to minimize API and behavioral differences while not breaking compatibility with existing .NET Framework applications.
But .Net Core has a different purpose than the .Net you know. It has no WinForms, no WPF, no lots of things.
Why ?Quote:
Originally Posted by SJWhiteley
He might have been thinking of JavaScript. You can never tell since members here seem to confuse the two constantly and the post was near other posts discussing the scripting language.
Oh i completely understand that i have read the info on it but even so being able to create apps in .NET which can be multi platform is only a positive in my opinion.Quote:
But .Net Core has a different purpose than the .Net you know. It has no WinForms, no WPF, no lots of things.
What i would be really nice for me personally is hosting ASP.Net solutions on Linux with apache.
I find IIS horrible to use and would much prefer to host all my web stuff on apache on linux.
I've had my issues with IIS as well.
What do you find better in Apache?
Even so , why a computer language needs to die?Quote:
Originally Posted by dilettante
No matter if it’s going to happen quietly or not.
Some out there use it. If anyone don’t want it , just don’t use it.
That simple.
P.S. Now I get the “quietly” part. Some other language failed to die “quietly”.
Because it does nothing for the end user except create a maze of frustration and perpetuates the 'computers are hard to use and just break sometimes' situation. It's a language that exists purely for the languages sake. It does nothing - absolutely nothing - well, and attracts those who can't program worth a damn; and that includes those who stick to the philosophy of 'pure programming' - the worst kind of a-hat that needs to be fed a diet of their own special kind of crap.Quote:
Originally Posted by JackB
Can hardly stand not answering it. :cool:Quote:
Originally Posted by szlamany
Quote:
Originally Posted by SJWhiteley
Let me ask you. What makes you think that the “end user” cares ?
Maybe it is the way all remained pure MASM devs (if any) think of all of us.Quote:
Originally Posted by SJWhiteley
This is Java syntax from an Android app I have - it's terrible - .equalsIgnoreCase() instead of just "="? The primitives of the language are rough to say the least.
Code:JsonObject ResultObject = JsonObject.readFrom(result);
for(String name : ResultObject.names())
{
if(name.equalsIgnoreCase("Type"))
{
if(ResultObject.get(name).asString().equalsIgnoreCase("Login"))
{
Toast.makeText(getBaseContext(), "Data Sent!", Toast.LENGTH_LONG).show();
if(!LoggedIn)
{
if(Controller.LoginParser(json2))
{
LoggedIn = true;
LoginResults = json2;
login.CallPostBootControls();
}
else
Yes, because some languages are case sensitive, not only in the language, but in the data...Quote:
.equalsIgnoreCase() instead of just "="?
So...
ResultObject.get(name).asString().equalsIgnoreCase("Login")
will fail if it's LoGiN... or login. so the equalsIgnoreCase means no matter what the casing is of the data, LoGiN and login will equal Login...
it's like doing this:
ResultDataRow.GetString(name).ToLower = "login"
it's ensuring it's apples to apples and lemons to lemons.
-tg
Obviously...
My point was that = is not allowed you have to use a method
Right, because = is an assignment, while == is the comparison operator... the reason to use a method is to be explicitly clear that the comparison is case insensitive...
I sit corrected... according to this comment I found on SO -
I guess in Java, everything is a reference object as opposed to a value object... huh.Quote:
Use the string.equals(String other) function to compare strings, not the == operator.
The function checks the actual contents of the string, the == operator checks whether the references to the objects are equal. Note that string constants are usually "interned" such that two constants with the same value can actually be compared with ==, but it's better not to rely on that.
-tg
I really, really, really don't like attacking a random code snippet as indicative that a language is terrible. Java certainly has some technical shortcomings, but good developers can work around them with different patterns.
I think the example has some poor concepts. The first thing I'm upset about is how deeply nested the ifs get. Then I ask, "What exactly does Controller.LoginParser() do, that's not a verb!" And I'm curious why we don't want to show a "Data Sent!" notification unless we specifically notice there's a "Type" : "Login" pair in the result. It makes no sense to me as-is because it's poorly structured. That's not Java's fault.
We could transcribe it directly, and it'd still be butt-ugly. Here's a representative snippet made "better" in VB:
I can't even tell I'm not reading the Java. This code stinks not because of "equalsIgnoreCase()", it stinks because it focuses on "how" instead of "what". We shouldn't write code that way. This is what it could look like in Java and be beautiful:Code:If ResultObject(name).ToString() = "Login" Then
NotifyIcon1.ShowBalloonTip(10000, "", "Data Sent!", ToolTipIcon.Info)
If Not LoggedIn Then
If Controller.LoginParser(json2)
All the "ugly" code is still there, hidden behind the facade of code that tells you WHAT it is doing rather than HOW.Code:notificationService.DisplayMessage("Data Sent!");
var result = JsonResult.FromJson(result); // Uses the parser, but converts JsonObject to something I want.
if (result.MessageType == MessageType.Login) {
AttemptLogin();
}
But even if it were ugly, let's talk about .equals() and .equalsIgnoreCase() vs. "just ==".
First, if you care about a case-insensitive compare, there's no way to tell VB to do so with just the operator. You have to do something like this:
That's not anything near as intent-revealing as equalsIgnoreCase(). How's VB .NET pull off a case-insensitive comparison?Code:If value1.ToUpper() = value2.ToUpper() ' BARF
Real slick. ;)Code:Dim valueEqual As Boolean = String.Compare(foo, bar, StringComparison.OrdinalIgnoreCase) = 0
The problem is not that "=" is not allowed. The problem is that in Java, "==" is strictly defined as a reference equality operator, and when you compare strings you want value equality. Since it's consistent across the entire language, you can just learn "comparing things with == is usually wrong" and go about your business. The story in .NET is much more complex. .NET did not strictly define the == operator as having value equality. Instead it opted for a set of rules, and the end result of the rules are this:
"To know what "==" does for an arbitrary type, check the documentation. It's usually value semantics for value types and reference semantics for reference types, but the default value type algorithm is sometimes wrong and in all cases Equals() might be overridden to have special rules. By default, you can't use operator== to compare two reference types. For strings, sometimes things get weird, and you shouldn't rely on reference equality alone."
That last bit's fun to demonstrate. Try and guess what this prints, then run it and see if you got it right.
Code:Sub TestStrings()
Dim value1 As String = "asdf"
Dim value2 As String = "asdf"
Dim value3 As String = ""
value3 &= "as"
value3 &= "df"
Console.WriteLine("Does value1 = value2? {0}", value1 = value2)
Console.WriteLine("Does value1 = value3? {0}", value1 = value3)
Console.WriteLine("Is value1 the same object as value2? {0}", Object.ReferenceEquals(value1, value2))
Console.WriteLine("So value1 and value3 are the same object? {0}", Object.ReferenceEquals(value1, value3))
End Sub
That code was written by someone that lasted here about 5 weeks - fresh out of college. That's what a headhunter got me...
It was only ever supposed to be a prototype and the client liked the look and feel of how it ran.
Now I've got to make real code out of it and my only experience with Java was watching this kid code. I remember fighting with him that "no one would use a method to compare a string - something you do on every other third line of code!). Apparently it does in the Java world.
There is so much taken for granted with the little old "=" symbol in VB. Does it compare - does it assign - how do I bit-check with and/or's. Maybe it's because the LET statement is assumed.
I think this is a bigger point than just VB. Maybe it's just me but I seem to be noticing a general trend toward imprecision in languages and I don't like it. In my last contract I worked in Python alot (seems to be all the rage in the Data Science world) and I hated how I had to wait until runtime before I could find out I'd just assigned a string where I wanted an integer. Gah! I've been teaching myself MVC and all the examples I find type everything as a var. I'm guessing that's a throwback to JavaScript but I see this even in controller examples and they're in C#. Even bigger Gah!Quote:
There is so much taken for granted with the little old "=" symbol in VB
I like languages that force me to be exlpicit. They keep me safe.
Edit>@TG and Sz, I'd been meaning to come back on your UI in the DB aproaches. 1. Nice work 2. Does this cuase any problems if you want multiple GUIs. I imagine you could support that by keeping multiple GUI definitions (for want of a better description) in the DB but I'm also willing to bet there's a sting or two in the tail that I haven't thought of. Is this something you've ever had to support and, if so, what were the hurdles?
One of the reasons I'm interested is that this aproach is simailar (in philosophy at least) to something I was trying recently and ultimately gave up on (at least for now - I may revisit it). I wanted a system where the major entities types were preset but the customer could define what those entities looked like, not just the UI but their properties. I tried an xml aproach where an xsd doc defined an entities schema, and xml doc defined an instance of an entity and an xslt doc defined how an entity would be presented on screen. These were all held in xml fields in the database. I think you're aproach is smiilar (in philosophy) to the xslt element of that set up.
4GL is what this is called
https://en.wikipedia.org/wiki/Fourth...mming_language
I make the base UI as simple as possible - with my web app it's a div called SYSTEM containing 4 div's arranged in a 2 x 2 matrix (top row BINDER, OPERATOR and bottom row TRACKER, WORK). These 4 div's are sized to look like your typical explorer-window with TRACKER being you object viewer and WORK being that big empty space)
All these DIV's are empty when the user gets on the page and the login popup appears.
After login the AWCConfig_T table shown below is returned in a boot-up sequence.
The ROLEID column has a number of a role that must be associated with that USERID that just logged in. This is one method I use to supply a different UI experience to different users.
Type "1" items below fill the OPERATOR space. The AWCWhat controls what is drawn - "button" is the only item supported at the moment.
Type "2" items tell the TRACKER "what to be" - the only option at the moment is a jQuery "accordion" - but I still drive it from the DB.
KISS means I have one source of UI meta data.
Type "3" items tell the TRACKER what to fill up with - basically a panel in each accordion.
You will see lots of JSON-strings that get EVAL()'d into native JavaScript variables. Some have k/v pairs needed by those UI elements - others have additional k/v pairs I need for logic hooks.
Then I have type "4" items to fill those corresponding panels - support DROPDOWN and AUTOCOMPLETEID.Code:AWCType AWCSeq RoleId AWCWhat Element AWCId AWCOptions
1 1 3 1 button btn-tasks { "text": "true" , "label": "Tasks" , "icons": { "primary": "ui-icon-clock" } }
1 2 5 1 button btn-vital { "text": "true" , "label": "Vital Statistics" , "icons": { "primary": "ui-icon-clipboard" } }
1 3 5 1 button btn-inspections { "text": "true" , "label": "Inspections" , "icons": { "primary": "ui-icon-clipboard" } }
1 4 5 1 button btn-complaint { "text": "true" , "label": "Complaints" , "icons": { "primary": "ui-icon-alert" } }
1 5 5 1 button btn-investigation { "text": "true" , "label": "Investigation" , "icons": { "primary": "ui-icon-star" } }
1 6 5 1 button btn-snap { "text": "true" , "label": "Establishment" , "icons": { "primary": "ui-icon-home" } }
1 7 5 1 button btn-qfo { "text": "true" , "label": "Food Operators" , "icons": { "primary": "ui-icon-cart" } }
1 8 5 1 button btn-housing { "text": "true" , "label": "Housing List" , "icons": { "primary": "ui-icon-home" } }
1 9 5 1 button btn-septic { "text": "true" , "label": "Septic Systems" , "icons": { "primary": "ui-icon-arrow-4-diag" } }
1 10 5 1 button btn-project { "text": "true" , "label": "Projects" , "icons": { "primary": "ui-icon-wrench" } }
1 11 13000 1 button btn-report { "text": "true" , "label": "Reporting" , "icons": { "primary": "ui-icon-note" } }
1 12 13000 1 button btn-display { "text": "true" , "label": "Displays" , "icons": { "primary": "ui-icon-calculator" } }
1 13 1 1 button btn-users { "text": "true" , "label": "Users" , "icons": { "primary": "ui-icon-person" } }
2 1 0 1 accordion trackerpanel { "collapsible": true , "autoHeight": false }
3 1 3 1 panel acs-task
3 2 3 1 panel acs-taskaddress
3 3 3 1 panel acs-establishment
3 4 5 1 panel acs-compwho
Note that I also have a SPROC name column in this table with optional prefix of ASYNC/ and optional parameters at the end.
Recently one of my clients had a need that I could not address through this setup. They are fine with all this for the in-house intranet version of the web app, but they also wanted a public facing version where vendors could connect and download bid specs for city jobs (argh - two IIS servers that I have to remembers to keep up-to-date with changes - I always forget that other one).Code:4 1 3 dropdown awcTask_autocompleteid @username { "minLength": 0, "choice2": "Check Here to Show All Tasks" }
4 2 3 autocompleteid async/awcTaskAddr_autocompleteid { "minLength": 0 }
4 3 3 autocompleteid async/awcEstablishment_autocompleteid { "minLength": 0 }
4 4 5 autocompleteid async/awcNonEstablishment_autocompleteid { "minLength": 0 }
4 5 5 dropdown awcSelectComplaint_autocompleteid @username { "minLength": 0 }
4 6 5 autocompleteid async/awcHousing_autocompleteid { "minLength": 0, "choice2": "Check Here to VIEW all addresses" }
4 7 5 autocompleteid async/awcHousing_autocompleteid { "minLength": 0 }
4 8 13000 dropdown awcReportNames_autocompleteid @username { "minLength": 0, "btnDefault": "report" }
4 9 13000 dropdown awcDisplayNames_autocompleteid @username { "minLength": 0, "btnDefault": "display" }
4 10 3 dropdown awcStaff_autocompleteid @username { "minLength": 0 }
At any rate for this situation I have a SiteSettings.JS file that the page loads early so that the DOM-READY event (FORM LOAD for you VB'ers) has additional meta data for initial screen setup.
And of course this is a JavaScript OBJECT with k/v pairs I can read up front and make UI elements hide.Code:// Include Site Specific settings below
var g_sitesettings = { RegisterLogin: false, HideBinder: false, SkipFilters: false, HideTracker: false, HideOperator: false, SingleTab: false, OperatorOpen: false };
//var g_sitesettings = { RegisterLogin: true, HideBinder: true, SkipFilters: true, HideTracker: true, HideOperator: true, SingleTab: true, OperatorOpen: true };
Vendors only see the WORK space and they get the OperatorOpen by default without hitting a button. They also have a REGISTER login popup since they can register via there email address.
I've got another table called AWCMobileConfig_T that tells my Android app how to boot up and maintain data.
@Funky - what do you mean by multiple GUIs? In our case our GUIS are defined by the GUID assigned to the XML meta data... so on a form, I can link an element or action to a specific GUID that defines the form to open. When I want to add a field to the form, I create an extension form, and define the parent ID as the ID from the original form. The system framework, when it goes to load a form, will load it, then look to see if there are any extensions that need to be loaded, then looks for any add-ins (non-GUI extensions) and loads them... then it renders the UI as per the loaded specs and displays it to the user.
-tg
As in, you want different classes of users to feel like they're using a comlpetely different app, albeit one that shares the same database and business logic layer.Quote:
what do you mean by multiple GUIs?
E.g. I worked on a marketting app a while back (it was desktop based so I apreciate the metaphor may break down a bit but it should suffice). We had several GUI executables. One for salesmen, one for the marketting department, one for the call centre and so on. These all shared the same business logic layer (we wanted that consistency of behaviour) and data but, from the users perspective, they were different applications. They had different look and feels, they were diferent exes etc.
I was curious whether you'd had similar requirements or whether you treat the whole application as one entity.
It was a few years ago when i used it but its just much easier to setup your website on Apache, you just edit a few lines in the Apache .config file, there is no confusing GUI interface like IIS.Quote:
I've had my issues with IIS as well.
What do you find better in Apache?
I built myself a Linux server put Apache on it (which was much easier than i was expecting) and then deploying a new version of my web application was just a case of pushing the new files to the server and doing an Apache restart. I had pretty much automated it to so it was sooo simple.
I know you can do similar things with IIS but i often have issue with automated deployment to ISS so i don't bother with it.
Also i didn't have to touch the server in 2 years apart form to push a new version to it, it just ran and ran. (that's more with it being Linux than Apache but the 2 come together really)
In our case it can be done... part of the meta data in the XML is a security folder. from the admin side you can grant or revoke access to different forms. So... if you need an admin form and a "user" form, they would be two specs in the system... then you would simply explicitly revoke access to the admin form for the user role, and explicitly grant it to the admin role. When an admin loggs in, they see the two forms, they can open either one up ... the typical user though would only see the one. Users only see the things they have access to. We can also manipulate the UI based on securoty context. We did that recently where the client wanted field-level securty rather than form level.... ungh... but OK... so in an addin for the form, we get the user context, find out if they had accces and if not, we set the fields to read-only. We also have the ability to use expressions in the Visible property of different elements on the UI... So tabs for instance, we can set a tab visible based on a filed value that comes back from the database. We use this a lot where we want to have one form across multiple dataviews because they are common to each other --- example: Employees and Managers... essentially they are just different classes of people... so we could create a single form with a bunch of tabs that they would use, contact, bio, projects, etc. But a manager is going to have Reportees... the employee won't... so the .Visibile field of the Reportees tab would be something like: "=FIELDS!IsManager" ... and IsManager would be a field that's returned by the expression stored proc for the page.... so if they are a manager, it will make the tab visible... if they are not, it will hide it.
-tg
I read a little more about your example - we would develop that in one app - each of those segments would be an "Area" which then consists of modules for specific functionality.Quote:
Originally Posted by FunkyDexter
So, we have a Marketing area... within it, we have Campaign modules, Appeals, Letters, and so on... as I previously mentioned, you can grant/revoke access... so the marketing people will see the Marketing modules, but not the Admin or Revenue modules... the accountants would see the Revenue and Fundraising, but not the Marketing... the call center would see the Constituent (people) modules, parts of the Revenue and parts of the Marketing (so they can answer calls when they come in)...
-tg