Alternatives
in [Visual Basic]
|
From: "Bill McCarthy" TPASoft.com Are Identity on 20 Jan 2009 22:44 "Frank" <youare(a)kidding.right> wrote in message news:5f5dn45n0ej7em9v6cier4or1g49ib6rve(a)4ax.com... > On Wed, 21 Jan 2009 13:00:03 +1100, "Bill McCarthy" <TPASoft.com Are > Identity Thieves> wrote mostly bull**it): > in <eRgsew2eJHA.3776(a)TK2MSFTNGP03.phx.gbl> > >> >>Never the less they don't encapsulate everything, and unless you have >>something that translates all our existing VB6 code to whatever does >>encapsulate what ever API you are using in the way you were using it, then >>this lack of support is a huge hurdle to using existing VB code. >> >>The win API calls of course is just one of the many issues. The lack of >>support for COM interop is probably even more significant. It's not like >>you can write a control in Jabaco and then use that on your VB6 forms. > > Yes, Billy McBarfy. These are obstacles purposely erected by Microsoft > to short circuit all attempts at interoperability. > What are you taking about "Frank" aka "Stephan" aak "me dotnyet" ?? Surely you know that Micorosft did provide for COm interop with it's implmentation of Java... it was Sun who said they didn't want that. > This community is not comprised of idiots like yourself. See above. > > And please cease and desist with your personal attacks. See above.
From: Schmidt on 21 Jan 2009 05:46 "Bill McCarthy" <TPASoft.com Are Identity Thieves> schrieb im Newsbeitrag news:eRgsew2eJHA.3776(a)TK2MSFTNGP03.phx.gbl... > Where does it "integrate" a JNI-wrapper ? You have to use the WinApi -Keyword instead of "Declare" The following is original Jabaco-Code: Public WinApi Function mciSendString Lib "winmm.dll" _ Alias "mciSendStringA" ( _ ByVal lpstrCommand As String, _ ByVal lpstrReturnString As String, _ ByVal uReturnLength As Long, _ ByVal hwndCallback As Long) As Long > Type libraries: not supported. That's COM - for COM there's already a great tool out there, you know... > JNI is very different from P/Invoke in .NET. But not less capable when it comes to external libs. > The half dozen or so features I listed, those which I > noticed within minutes of trying out Jabaco, are pretty > much show stoppers for any porting of any serious > VB6 app, As already said, it is a young project, give it some time. As soon as the mapping against the Java-Classes per VB-Syntax is rockstable, I cannot imagine why you shouldn't be able to write large and serious Applications with it - Java can create/handle such Applications. > not that there is even a porting tool. You mean something like the not working "MS-wizzard" has to offer... <g> > So in terms of the original posters question of looking for > something which he can apply his VB6 knowledge, Vb > .NET is a hundred fold better. Not from my point of view - from what I experienced with VB-Classic I cannot recommend MS-based environments (which are not in broad usage with MS internally) seriously to anyone, sorry. > - one who has decided to use one of the > > managed frameworks like Java or .NET should avoid > > using the System-APIs - that's why these libs are so huge - > Then why is there JNI or P/Invoke ? Because sometimes one cannot avoid calling the system-api. And as demonstrated, Jabaco allows that too - quite easy. I only wondered a bit, why you as a "great .NETer", have missed the SystemAPI-access so much - in many arguments with the .NETers here there's often stated, that .NET is the "new WinAPI" - and that the old WinAPI is soon going "out of scope" (just to spread a little bit of FUD). Now you come along and blame a new tool (which already wraps most of the SystemAPI in classes) for not offering WinAPI-access. > The win API calls of course is just one of the many issues. > The lack of support for COM interop is probably even > more significant. Why should *we* need any COM-support - we already know the best COM-tool on this planet very well - and this tool (aka VB-Classic) will work the next years without problems. > It's not like you can write a control in Jabaco and then use that > on your VB6 forms. I never understood, why anybody should use such a mess like the "Winform-Interop-Toolkit" (maybe for a nice button, yes?) and blow up his VB6-Apps this way. Either migrate "fully" (without any COM) or stay with VB6. And that holds true also for Jabaco - no one, who want's to seriously migrate his App to one of the managed frameworks should consider COM on these new environments - and if one migrates, he should ensure from the very beginning, that the App runs not only on Windows, but also on other platforms. That's what these huge managed libs are made for (at least Java and Mono) - platform-independency! Olaf
From: Henning on 21 Jan 2009 07:03 "Bill McCarthy" <TPASoft.com Are Identity Thieves> skrev i meddelandet news:%23fFjgt2eJHA.1168(a)TK2MSFTNGP05.phx.gbl... > Hi Henning, > > "Henning" <computer_hero(a)coldmail.com> wrote in message > news:4975c001$0$12243$57c3e1d3(a)news3.bahnhof.se... >> >> "Bill McCarthy" <TPASoft.com Are Identity Thieves> skrev i meddelandet >> news:%238h$r9ceJHA.3692(a)TK2MSFTNGP04.phx.gbl... >>> >>> "Ken Halter" <Ken_Halter(a)Use_Sparingly_Hotmail.com> wrote in message >>> news:OKNRBetdJHA.5344(a)TK2MSFTNGP05.phx.gbl... >>>> >>>> Holy smokes! An unbiased opinion! Say it ain't so! >>> >>> "Unbiased" is when you look at the facts Ken, not when you post a link >>> to some software you haven't even tried and then tack on a heap of anti >>> Microsoft nonsense claiming the current global credit squeeze is due to >>> Microsoft <unbelievable/> >>> >>> I suggest you actually look at Jabaco. You will find it is a poor VB >>> implementation on top of Java. There's not even a Debug.Print. form's >>> are missing dozens of properties and because it is based on swing, there >>> isn't even a form's hWnd. You cannot use API of any king, no type >>> libraries, no COM components. And again, because it is based on Java, >>> you've got that GC object model lifetime issues (lack of determinalistic >>> finalization). Rather than expose that, they just cut out the Terminate >>> event entirely from the class modules. It's totally lame. >>> If you want to code against Java, use Java. You'll find there's lots of >>> tools, support, samples etc. >> >> I've tried it a bit with an existing app. It isn't *that* bad, and you >> have to concider it's still in beta stage. If you wish you can call any >> Java function directly. >> >> Give Manuel a little time to at least pass bata before judging. >> > > Well we can only judge by what is there. If Manual's intentions are to > support more VB6 features he should say that. In fact, a write up of what > language features he is and isn't supporting would be a really good thing > to get people interested, otherwise it's impossible to tell if it is just > taking the low hanging fruit and not going to address the more > significant/difficult issues. > Reading the German community discussions points to a serious intention. Only time will show if more programmers start to contribute, and the framework is opensource. /Henning
From: "Bill McCarthy" TPASoft.com Are Identity on 21 Jan 2009 20:47 "Schmidt" <sss(a)online.de> wrote in message news:OXEPqY7eJHA.1168(a)TK2MSFTNGP05.phx.gbl... > > "Bill McCarthy" <TPASoft.com Are Identity Thieves> schrieb im Newsbeitrag > news:eRgsew2eJHA.3776(a)TK2MSFTNGP03.phx.gbl... > >> Where does it "integrate" a JNI-wrapper ? > You have to use the WinApi -Keyword instead of "Declare" > Thanks. I would never have guessed that one. Why the change ? > The following is original Jabaco-Code: > > Public WinApi Function mciSendString Lib "winmm.dll" _ > Alias "mciSendStringA" ( _ > ByVal lpstrCommand As String, _ > ByVal lpstrReturnString As String, _ > ByVal uReturnLength As Long, _ > ByVal hwndCallback As Long) As Long > Okay but how do I do EnumChildWindows or CopyMemory ? I can't get AddressOf, or VarPtr etc to work. Is As Any supported too ? > >> Type libraries: not supported. > That's COM - for COM there's already a great tool > out there, you know... > And you can't integrate with it. considering the Jabaco IDE itself is written in VB6 and COm, it's a share you can't write anything with Jabaco that can work with Jabaco ;) >> JNI is very different from P/Invoke in .NET. > But not less capable when it comes to external libs. > That really depends on how hte language surfaces that. P/Invoke allows you to write all the variations of how you want the call to be made using .NET languages. JNI on the other hand requires the generation of a specially crafted native assembly. If Jabaco manages to surface only what Vb6 has there, it is significnatly less than what P/Invoke allows. >> The half dozen or so features I listed, those which I >> noticed within minutes of trying out Jabaco, are pretty >> much show stoppers for any porting of any serious >> VB6 app, > As already said, it is a young project, give it some time. As I said, there is no roadmap or inidcation of where he is taking it. > As soon as the mapping against the Java-Classes per > VB-Syntax is rockstable, I cannot imagine why you > shouldn't be able to write large and serious Applications > with it - Java can create/handle such Applications. > Sure, but it won't work with your *exisitng* VB6 code and that is the point. >> not that there is even a porting tool. > You mean something like the not working "MS-wizzard" > has to offer... <g> > Well there's that or plenty of other ones. And there is COM interop. Jabaco has none of these. >> So in terms of the original posters question of looking for >> something which he can apply his VB6 knowledge, Vb >> .NET is a hundred fold better. > Not from my point of view - from what I experienced with > VB-Classic I cannot recommend MS-based environments > (which are not in broad usage with MS internally) seriously > to anyone, sorry. > Visual Studio is in broad use within Microsoft as is the .NET framework. And there are open source alternatives of .NET IDe's as well (SharpDevelop) and 3rd party ones as well. So lots of choice for your code assets. Compared to some young guy running a one man show with closed source (yes Jabaco is actually closed source for the IDE and compiler), then .NEt seems a much smarter move. Or alternatively, if you want ot move to Java and away from MS, then move to Java/Eclipse et al . >> - one who has decided to use one of the >> > managed frameworks like Java or .NET should avoid >> > using the System-APIs - that's why these libs are so huge - > >> Then why is there JNI or P/Invoke ? > Because sometimes one cannot avoid calling the system-api. > And as demonstrated, Jabaco allows that too - quite easy. > Okay so you seemed to be arguing that you don't need it. Now you saying that you do. > I only wondered a bit, why you as a "great .NETer", have > missed the SystemAPI-access so much - in many arguments > with the .NETers here there's often stated, that .NET is > the "new WinAPI" - and that the old WinAPI is soon > going "out of scope" (just to spread a little bit of FUD). LOL. See above re FUD ;) > Now you come along and blame a new tool (which already > wraps most of the SystemAPI in classes) for not offering > WinAPI-access. > I said it doesn't work with most of my VB6 code. Win API was just one of the half dozen or things I came up against within minutes of testing it. I'm curious as to why you focused so much on that and at first didn't even say there was a changed syntax for Declares. What I find mildly amusing is how there use to be such a fuss about things like "Wend" being changed to "End While", but yet when some guy decides to change Declare to WinAPI, no fuss is made at all. ;) > >> The win API calls of course is just one of the many issues. >> The lack of support for COM interop is probably even >> more significant. > Why should *we* need any COM-support - we already > know the best COM-tool on this planet very well - and this > tool (aka VB-Classic) will work the next years without > problems. > So as the two can actually work together and communicate with each other. So as you can use your current COM based assets in the new tool. etc, etc, etc.
From: "Bill McCarthy" TPASoft.com Are Identity on 21 Jan 2009 20:49
Hi Henning, "Henning" <computer_hero(a)coldmail.com> wrote in message news:49773040$0$16212$57c3e1d3(a)news3.bahnhof.se... >> >> Well we can only judge by what is there. If Manual's intentions are to >> support more VB6 features he should say that. In fact, a write up of >> what >> language features he is and isn't supporting would be a really good thing >> to get people interested, otherwise it's impossible to tell if it is just >> taking the low hanging fruit and not going to address the more >> significant/difficult issues. >> > > Reading the German community discussions points to a serious intention. > Only > time will show if more programmers start to contribute, and the framework > is > opensource. > Jabaco itself is not open source. The parser, compiler, IDE are all closed source (all written in VB6 / COM as far as I can tell). Manuel was also quite coy about whether or not the product will remain free, indicating it is his intent to charge for it once he gets enough people roped in. |