Page 1 of 5 1234 ... LastLast
Results 1 to 40 of 170

Thread: Is the VB6 community capable to grab the bull by its horns?

  1. #1

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,996

    Cool Is the VB6 community capable to grab the bull by its horns?

    I know we are tired, the time has passed and we had no solution for VB6 to date.

    I also know that there are some projects going on, like TwinBasic, I wish the best luck and great success, and I hope they will have something working as soon as possible.
    But we can't just sit back and wait any longer for something to happen.
    If we keep waiting, doing nothing, the things will become only worse over time.

    My suggestion/proposition is:

    To split the large problem into smaller pieces.

    No one needs to develop a full VB6 replacement, but can contribute with some part.

    But... for that, we need to know what are these pieces. And then how can anybody contribute with a part of a piece.

    If someone thinks he has to do everything, it will be until 2050 to be able to show something.

    I don't think I am the one to lead this project, because if I was, I would not be askling this question, but giving the answer: describing what are the pieces already isolated and specifying clearly how they must interact with each other.
    But it is a proposition for the ones that has knowledge on this field.
    Myself I don't have a C or ASM background.
    OK, I could learn, but that would take too long. It is not practical (and we are too late already).

    These pieces, I think, they would be the IDE, compiler, runtime, etc.
    More and smaller pieces there are, the better.

    I could contribute with some parts I think, if there was a project like this.
    Maybe the Printer object, some functions.
    We already have Krool's controls. The PictureBox is not covered but it could be done, I have the SStab too.

    Let's start doing something. Something that can be scaled/perfected.
    It does not need to be fully optimized in the first version. I mean, if some function, lets say [tt]Split[tt], is not as fast as the VB6 one, no problem. It can be optimized later.

    I suggest the first goal not to try to make something better than the original VB6, the first goal is to replace the original VB6 as it is.
    But with the source code, where we can build over it and develop further.
    Not to be compilable on Linux, 64 bits, etc.
    64 bits support will be of cource one of the first steps further, but first the first.
    Do not expect too much for the first version, just to replace what we have now (and only then start dreaming).

    I do not expect someone to post a full specification tomorrow, but perhaps some day.

    If at a point only some part is done, OK, we will have a new IDE, or a new compiler. Not the whole project but at least some part was already replaced.

    Please let me know what do you think (specially the ones capables of doing this separation and specification).

    But also the question: is this possible? Does this proposition make sense?

    PS: this should have happened like 10 years ago at least, but OK, it didn't happen, and we are here and still need it.

    This should not be something about egos, we all know who the geniuses are, don't need to prove it any more. What we do need is a new VB (at least the same, but with future).

  2. #2
    PowerPoster
    Join Date
    Jun 2012
    Posts
    2,375

    Re: Is the VB6 community capable to grab the bull by its horns?

    We need a Resource Editor replacement. LaVolpe is doing an AddIn. Though I don't know the progress, hopefully not abandoned.

  3. #3

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,996

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by Krool View Post
    We need a Resource Editor replacement. LaVolpe is doing an AddIn. Though I don't know the progress, hopefully not abandoned.
    OK, yes, we need several things.
    I was thinking also on a Package and Deplayment Wizzard replacement. There are people here that could do it I guess (for example dilettante -if he wants to-, or even myself)

    But to be encouraged to spend time on these satellite parts, I'm concerned first with the heart.
    And that was the main purpose of the thread, to try to set some point on how the IDE/compiler/runtime stuff can be attacked.
    I could contribute with things that can be done in VB6, but those other things require other knowledge (that I don't currently have).

    BTW: I never used the resource editor .

  4. #4
    PowerPoster yereverluvinuncleber's Avatar
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    2,235

    Re: Is the VB6 community capable to grab the bull by its horns?

    Absolutely, it is 10 years too late and yes it should have been done just as you laid out, I am sure I and others have said the same several times in the past. It just needs someone competent to grasp the nettle.

    However, RADBasic and TwinBasic seem to be real projects actually making genuine progress so perhaps we could support those two projects instead or as well? Anything that keeps VB6 alive and makes it a supported language, gaining a supported compiler, IDE and debugger takes VB6 out of obsolescence, so we should support TwinBasic and RADBasic.

    If there is still the need for a community-driven VB6 after these projects succeed (or fail) then perhaps we should start to put the effort in. I think your call to arms has come at a point where VB6 interest is actually at a peak but your call to arms should have happened five years ago when these projects didn't exist.

  5. #5

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,996

    Re: Is the VB6 community capable to grab the bull by its horns?

    As I said, I wish them great success and hope they won't fail.
    But I don't think we should keep seated back just waiting. Few things happen that way in life, and this particular one already showed not to honor that strategy. That would be not to grab the bull by its horns and hope someone else does. (or maybe I'm being impatient. It is 2021 already anyway).
    If at the end there are several alternatives replacing VB6, the better.

    We should have done this 5 years ago? Yes, or may be 15. But we didn't do it. And the more we wait, the worse.
    Anyway, on the other hand, I'm quite sure that everyone learned a lot, so now we are in a better position than 10 years ago to do it.

    About to contribute, I'm not sure what you mean, I think they are private closed source projects, I could contribute to a community driven project like the outlined here.

  6. #6
    Hyperactive Member
    Join Date
    Jun 2016
    Location
    España
    Posts
    506

    Re: Is the VB6 community capable to grab the bull by its horns?

    very good idea.
    I am not a great programmer, but ideas and help I can give.

    a greeting

  7. #7

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,996

    Re: Is the VB6 community capable to grab the bull by its horns?

    Then the issue is:
    -We should wait.
    -It is too late (we waited for too long).

    My perspective is:
    We should not wait, and never is too late (at least I don't think it is now).

    Also, the issue is to keep the morale high, and that will happen if we knew we are working towards a solution (doing something for ourselves and not waiting for a savior or a miracle).

    Otherwise, better to think in going to do something else (that is what I'm already thinking, but I was not supposed to say that).

  8. #8
    Fanatic Member
    Join Date
    Jun 2019
    Posts
    557

    Re: Is the VB6 community capable to grab the bull by its horns?

    Prepare initial list of requirements what this new "VB6" (as it will be no VB6 by definition) should include: IDE, forms designer, compiler, runtime, language features (projects, classes, modules, procedures, functions, conditionals, loops, etc.), platform/stack features (UI, graphics, databases, COM, Win API, network, messaging, cryptography, ...), extensibility (of compilers, IDEs, different editors, debuggers) and whatever you have in mind.

    This initial list will be expanded via discussions in the forum or somewhere else with more and more features and requirements - some of them realistic, some not. But every requirement should be explained how, where and why it was used or will be used and maybe an example that will explain it better for other people that will work on the project. Because "I want to compile my existing VB6 app with the new compiler and everything to work as it was before" is not requirement.

    After the initial list of requirements is prepared, it will be discussed and filtered. Setting right priorities of features or requirements is also viable part of that process.

    Without all steps above this thread will be just another in the bunch of "new VB6" threads where people talk how VB6 is great and don't distinguish programming language features from technical platform/stack.

  9. #9
    Member
    Join Date
    Nov 2020
    Posts
    35

    Re: Is the VB6 community capable to grab the bull by its horns?

    Hi there

    I think if we can extend VB6 to target Linux my be it would be better..
    I like VB6 and I will love it forever ..
    thank you

  10. #10

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,996

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by peterst View Post
    "I want to compile my existing VB6 app with the new compiler and everything to work as it was before" is not requirement.
    That's exactly the requirement.

    And we already have that with the original VB6.

    The idea of this thread is to get the original VB6 replaced part by part, one at a time.

    Then, the purpose is to get someone that has the knowledge and is capable of defining the parts interested and help with that.

    At least to advance one step and know how this monster can be butchered.

    I know I can't contribute with parts like the compiler. Perhaps no one here could contribute with all the parts. But someone could say "I could do that part", and someone else "I can work on this other part".
    That's the idea. To replace the existing VB6, part by part.

    For the initial requirement of this new VB, as I explained in the OP, not to go further than what VB6 does now.
    I would say less, there are some things that no one uses, like projects type Application DHTML, UserDocuments, those could (and should) be taken out. But I don't think they are many.

  11. #11
    The Idiot
    Join Date
    Dec 2014
    Posts
    2,721

    Re: Is the VB6 community capable to grab the bull by its horns?

    I think the first step would be:

    - learn how VB6 was made, recreate the steps, maybe even start from VB1
    - create the immediate window, add some basic stuff, math and string handling and nothing more

    I think u need to start low, and see if you can do it.
    if it works. add 1 more feature and go from there.

  12. #12
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by Eduardo- View Post
    Myself I don't have a C or ASM background.
    OK, I could learn, but that would take too long. It is not practical (and we are too late already).
    C and Assembly aren't actually as difficult as you think. Based on your posts, I'm confident you can learn both inside of a month. Now don't expect to be able to understand how to write an OS after just a little studying but you can begin writing actual working code in both languages comfortably in very little time.

    Knowledge of ASM and C would be important for development of a compiler. I'd estimate about 6 months of intense studying would be enough for you to be able to write a rudimentary compiler.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  13. #13

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,996

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by Niya View Post
    C and Assembly aren't actually as difficult as you think. Based on your posts, I'm confident you can learn both inside of a month. Now don't expect to be able to understand how to write an OS after just a little studying but you can begin writing actual working code in both languages comfortably in very little time.

    Knowledge of ASM and C would be important for development of a compiler. I'd estimate about 6 months of intense studying would be enough for you to be able to write a rudimentary compiler.
    Maybe, but bringing it even more to reality, and following my rule (not only mine) that the projects always take at least three times the initial estimate, then that would be 18 months of intense stydy/work. Just to be able to start (working in a compiler).

    I was hoping that someone else could be already ready for that.
    Anyway... never say never. I currently am not planning to do that, but I already did many things that I didn't plan to do in the past. But that's not what I'm curretly considering to do.

    I'm just offering to contribute with things I already know.
    It is only a suggestion, a proposition to others.
    I can't do it myself (at least not now).
    But I'm not going to quit this battle having all the bullets fired, even if I fire them to the air.

    Seat back and wait what happens? I'm tired to be seated, and nothing happens (only bad things happen).

    PS: I word of disclaimer: I do not guarantee that I'll be able to contribute or how much. If find something more convenient to do, may be I won't have time (and I hope so).
    But anyway I'm throwing this idea to the community.

  14. #14
    Fanatic Member
    Join Date
    Jun 2019
    Posts
    557

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by Eduardo- View Post
    Quote Originally Posted by peterst View Post
    "I want to compile my existing VB6 app with the new compiler and everything to work as it was before" is not requirement.
    That's exactly the requirement.

    And we already have that with the original VB6.

    The idea of this thread is to get the original VB6 replaced part by part, one at a time.

    Then, the purpose is to get someone that has the knowledge and is capable of defining the parts interested and help with that.

    At least to advance one step and know how this monster can be butchered.
    ...
    So why don't you stick with existing VB6? It exactly fulfills your requirement.

    Is it so hard to start writing list with _real_ requirements? Initial analysis and proper definition of requirements are the key for success. Dig into details, document them, propose improvements with comparison to existing features.

    Here I will write example for some real requirement and why it is unrealistic:

    [REQ]
    New compiler should make Linux binaries

    [ANALYSIS]
    The analysis and other requirements like 100% compatibility with old VB6 projects will make that impossible as many projects and libraries are using Win32 API declarations and these, for obvious reasons, don't exist under Linux.

    [CONCLUSION]
    Linux compatible compiler will be made in future version and it will be available for projects where:
    - no Win32 API declarations are used and there
    - no Forms UI as there is no graphical user interface engine to perform the layout of forms and controls which are made for Windows.
    - TODO: add more limitations if any

  15. #15
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: Is the VB6 community capable to grab the bull by its horns?

    Let me point out that you are 14 posts into this thread and already the objective is blurring. This is the problem that has always plagued VB6 replacements, even including VB.NET: In theory, it's a great idea. In practice, everybody wants something slightly different.

    If you get what YOU want, you'll be happy, as I was with .NET. If you do NOT get what you want, you'll be unhappy. The very nature of this type of project means that some will be happy, others unhappy. The ones that end up unhappy with the choices made with the new language/IDE/tools, will be in the same boat they currently are, just with fewer fellow passengers.

    I'd say that you need to come up with one clear objective, but I don't believe that is possible. The various objectives that people have stated are all quite reasonable and worthy. They are not all necessarily mutually compatible, though.
    My usual boring signature: Nothing

  16. #16

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,996

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by peterst View Post
    So why don't you stick with existing VB6? It exactly fulfills your requirement.
    Please read the OP and other posts by me in the thread. That question is very well answered (at least I think so).

    Quote Originally Posted by peterst View Post
    Is it so hard to start writing list with _real_ requirements? Initial analysis and proper definition of requirements are the key for success. Dig into details, document them, propose improvements with comparison to existing features.

    Here I will write example for some real requirement and why it is unrealistic:

    [REQ]
    New compiler should make Linux binaries

    [ANALYSIS]
    The analysis and other requirements like 100% compatibility with old VB6 projects will make that impossible as many projects and libraries are using Win32 API declarations and these, for obvious reasons, don't exist under Linux.

    [CONCLUSION]
    Linux compatible compiler will be made in future version and it will be available for projects where:
    - no Win32 API declarations are used and there
    - no Forms UI as there is no graphical user interface engine to perform the layout of forms and controls which are made for Windows.
    - TODO: add more limitations if any
    Again, in the OP (and other posts) is the answer.
    I'm asking (well, not asking, just propossing, suggesting) to other people something that I'm not able to do: to split this large problem into smaller pieces.
    There are not requirements list for that, it is just VB6 as a whole, minus certain features, like UserDocuments, that are never used.

    Once the whole thing is already splitted into pieces, we could make a requirement list for each one piece.
    But for some pieces I have not idea what the requirements should be, for example the compiler.

    So, the "requirement" is quite simple to define: to replace VB6 as it is, but piece by piece.
    And also the "requiirement" is help defining the pieces, their boundaries, how they interact with the other pieces.

    In some way it is more like I'm asking to someone with more knowledge to make the "requirements list" and specifications that you say. If I was able to do it myself I would not be asking.

  17. #17

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,996

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by Shaggy Hiker View Post
    Let me point out that you are 14 posts into this thread and already the objective is blurring. This is the problem that has always plagued VB6 replacements, even including VB.NET: In theory, it's a great idea. In practice, everybody wants something slightly different.

    If you get what YOU want, you'll be happy, as I was with .NET. If you do NOT get what you want, you'll be unhappy. The very nature of this type of project means that some will be happy, others unhappy. The ones that end up unhappy with the choices made with the new language/IDE/tools, will be in the same boat they currently are, just with fewer fellow passengers.

    I'd say that you need to come up with one clear objective, but I don't believe that is possible. The various objectives that people have stated are all quite reasonable and worthy. They are not all necessarily mutually compatible, though.
    The objective is very clear, and there is no something that someone wants, and another one does not want, because what I'm proposing is to replace VB6 as it is now, no more, not less.

    No Linux compilation, no 64 bits support, not nothing.

    After we acchieve that, there could come what you say.
    OK, I don't mind if the project goes into 20 branches, everyone could do the VB6.1 that he wants, I don't see a problem with that.

  18. #18
    Fanatic Member
    Join Date
    Jun 2019
    Posts
    557

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by Eduardo- View Post
    Please read the OP and other posts by me in the thread. That question is very well answered (at least I think so).



    Again, in the OP (and other posts) is the answer.
    I'm asking (well, not asking, just propossing, suggesting) to other people something that I'm not able to do: to split this large problem into smaller pieces.
    There are not requirements list for that, it is just VB6 as a whole, minus certain features, like UserDocuments, that are never used.

    Once the whole thing is already splitted into pieces, we could make a requirement list for each one piece.
    But for some pieces I have not idea what the requirements should be, for example the compiler.

    So, the "requirement" is quite simple to define: to replace VB6 as it is, but piece by piece.
    And also the "requiirement" is help defining the pieces, their boundaries, how they interact with the other pieces.

    In some way it is more like I'm asking to someone with more knowledge to make the "requirements list" and specifications that you say. If I was able to do it myself I would not be asking.
    If you can't write real requirements, then it is lost cause. If you can't split your requirement and expect someone else to do it, then I really can't imagine how you manage with software development as it is taking the task as requirement, split it into subtasks and develop part by part.

  19. #19

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,996

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by peterst View Post
    If you can't write real requirements, then it is lost cause. If you can't split your requirement and expect someone else to do it, then I really can't imagine how you manage with software development as it is taking the task as requirement, split it into subtasks and develop part by part.
    I think you are not reading. I understand, I'm sometimes lazy to read too.

    PS: If you are expecting me to describe to the masters what VB6 is, what is does, and what parts it has (from the IDE-user point of view), they already know that beter than me.

    PS2: OK, I could do that if requested. Perhaps it could help.

  20. #20
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Is the VB6 community capable to grab the bull by its horns?

    There is already a 100% VB6 compatible substitute on the way, TwinBasic. It's actively being developed and already has an array of very impressive features considering there's only about 2 people working on it. This is the most promising prospect I've ever seen when it comes to a substitute for VB6. You guys need to keep a close eye on that and give the developers some encouragement. Real talk, this project is already too far ahead for anyone to come now and try to do the same thing from scratch. It would just be wasted effort. They already have an IDE and a compiler. Better to get on board with TwinBasic and hope for the best.

    If you guys are serious, you should contact the developers and see how if he is willing to accept any help. There is enough talent here to give a serious boost to that project.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  21. #21

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,996

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by Niya View Post
    There is already a 100% VB6 compatible substitute on the way, TwinBasic. It's actively being developed and already has an array of very impressive features considering there's only about 2 people working on it. This is the most promising prospect I've ever seen when it comes to a substitute for VB6. You guys need to keep a close eye on that and give the developers some encouragement. Real talk, this project is already too far ahead for anyone to come now and try to do the same thing from scratch. It would just be wasted effort. They already have an IDE and a compiler. Better to get on board with TwinBasic and hope for the best.

    If you guys are serious, you should contact the developers and see how if he is willing to accept any help. There is enough talent here to give a serious boost to that project.
    I alrready talked about Twinbasic on post #5 and #1.

    Also note that this is a propietary closed source project.
    This means that we would be in a better position only because they are nicer people than MS.

  22. #22
    Fanatic Member
    Join Date
    Jun 2019
    Posts
    557

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by Eduardo- View Post
    I think you are not reading. I understand, I'm sometimes lazy to read too.

    PS: If you are expecting me to describe to the masters what VB6 is, what is does, and what parts it has (from the IDE-user point of view), they already know that beter than me.

    PS2: OK, I could do that if requested. Perhaps it could help.
    Adding more and more requirements where some of them are really improving the product will let the people who will do the deep analysis think what and when it is suitable to add a feature. Because if the new product is not designed for extensibility and developers didn't have time to think about _before_ real implementation, later they will need to change or rewrite lot of pieces of the app.

    So if you want really to contribute - start first and write real requirements, don't wait others. Also such job will require to organize all requirements, ideas and documentation so it is easy accessible. Even small contributions are important - fix spelling, white spaces or even punctuation. Not everything is code in large projects.

  23. #23

    Thread Starter
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,996

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by peterst View Post
    Adding more and more requirements where some of them are really improving the product will let the people who will do the deep analysis think what and when it is suitable to add a feature. Because if the new product is not designed for extensibility and developers didn't have time to think about _before_ real implementation, later they will need to change or rewrite lot of pieces of the app.

    So if you want really to contribute - start first and write real requirements, don't wait others. Also such job will require to organize all requirements, ideas and documentation so it is easy accessible. Even small contributions are important - fix spelling, white spaces or even punctuation. Not everything is code in large projects.
    OK, as I said, I can do that. But first I want to see someone interested.
    Yes, it makes sense. I will have to "study" VB6 in detail from the usability point of view.

  24. #24
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by Eduardo- View Post
    But first I want to see someone interested.
    This horse has been beaten to death on this forum. This thread is not the first of it's kind. I wouldn't get my hopes up on this going anywhere. None of the others did. It's safe to say at this point that we know where everyone stands. We already know from the other threads like this who is interested in contributing, who is not, who the cheerleaders are, who thinks it's all talk, who don't care one way or the other etc.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  25. #25
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by peterst View Post
    Here I will write example for some real requirement and why it is unrealistic:

    [REQ]
    New compiler should make Linux binaries
    I fully agree with that requirement or goal.
    Platform-independence is the most important thing for a new compiler (and especially IDE),
    with regards to "long-term-attractiveness" (for new developers).

    A "new thing", which only supports the windows-platform will be "dead in the water" -
    because there's always the "good old VB6-IDE" as the main-competitor (which will work for many more years to come).

    Quote Originally Posted by peterst View Post
    [ANALYSIS]
    The analysis and other requirements like 100% compatibility with old VB6 projects will make that impossible as many projects and libraries are using Win32 API declarations and these, for obvious reasons, don't exist under Linux.

    [CONCLUSION]
    Linux compatible compiler will be made in future version and it will be available for projects where:
    - no Win32 API declarations are used and there
    - no Forms UI as there is no graphical user interface engine to perform the layout of forms and controls which are made for Windows.
    Your concerns are quite right.

    But that's exactly the reason, why I've put so many years of efforts into new, modern Runtime-Classes -
    which in the meantime:
    - are battle-hardened and bug-free (aside from very rarely up-coming "corner-case-bugs")
    - are already avoiding huge parts of the Win32-API under the covers (using platform-independent libs instead, especially for the GUI)
    - and due to that, these Runtime-Classes will be easily portable to e.g. Linux
    The new RT-Classes are all contained in vbRichClient5.dll (or the new, slightly enhanced RC6-lib)

    And since this lib is available for quite some years now already -
    any VB6-Developer could have bound this lib as the sole reference into his VB6-Projects -
    and then (with the help of the contained RT-Classes) build modern VB6-Apps without any Win32-API-declares.

    So, VB6-Apps which contain only normal VB6-code, and then work through this "Abstraction-layer" (for the more advanced stuff, not available via msvbvm60.dll),
    are - without any code-changes - directly recompilable for a new platform (e.g. Linux, Mac, whatever).

    Besides our own (current) VB6-Apps, which could be developed in this way (for a few years now) -
    this should definitely include also the new to develop Visual-IDE (including the new Form-Designer).

    So, the only necessary requirements for these "portable VB6-Apps" which will later work also on Linux are:
    - a new compiler which only needs to support a compilation of *.cls and *.bas modules
    - the above being a necessity, to recompile the RC6-lib for "64Bit-mode" on Windows - but also for "the Linux-platform"
    - because with an existing RC6_Win64-lib (or an existing RC6_Linux64-lib)
    - all the "normal VB6-Code" (which used the RC6-Classes and their methods) will run without larger problems on any platform

    In my opinion, anything "Visual-IDE-like" which is not developed against platform-independent (GUI-)libs from the get-go,
    will not survive long-term.

    As said already - the problem of (for the most parts) already platform-independent Runtime-Classes is already solved.
    What remains is, that these Classes (which provide the necessary Abstraction-Layer for platform-independence of VB6-Code written "on top"),
    are used (to produce the new Compiler and new IDE).

    Olaf
    Last edited by Schmidt; Jan 20th, 2021 at 01:32 PM.

  26. #26
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by Schmidt View Post
    Your concerns are quite right.

    But that's exactly the reason, why I've put so many years of efforts into new, modern Runtime-Classes -
    which in the meantime:
    - are battle-hardened and bug-free (aside from very rarely up-coming "corner-case-bugs")
    - are already avoiding huge parts of the Win32-API under the covers (using platform-independent libs instead, especially for the GUI)
    - and due to that, these Runtime-Classes will be easily portable to e.g. Linux
    The new RT-Classes are all contained in vbRichClient5.dll (or the new, slightly enhanced RC6-lib)

    And since this lib is available for quite some years now already -
    any VB6-Developer could have bound this lib as the sole reference into his VB6-Projects -
    and then (with the help of the contained RT-Classes) build modern VB6-Apps without any Win32-API-declares.

    So, VB6-Apps which contain only normal VB6-code, and then work through this "Abstraction-layer" (for the more advanced stuff, not available via msvbvm60.dll),
    are - without any code-changes - directly recompilable for a new platform (e.g. Linux, Mac, whatever).

    Besides our own (current) VB6-Apps, which could be developed in this way (for a few years now) -
    this should definitely include also the new to develop Visual-IDE (including the new Form-Designer).

    So, the only necessary requirements for these "portable VB6-Apps" which will later work also on Linux are:
    - a new compiler which only needs to support a compilation of *.cls and *.bas modules
    - the above being a necessity, to recompile the RC6-lib for "64Bit-mode" on Windows - but also for "the Linux-platform"
    - because with an existing RC6_Win64-lib (or an existing RC6_Linux64-lib)
    - all the "normal VB6-Code" (which used the RC6-Classes and their methods) will run without larger problems on any platform

    In my opinion, anything "Visual-IDE-like" which is not developed against platform-independent (GUI-)libs from the get-go,
    will not survive long-term.

    As said already - the problem of (for the most parts) already platform-independent Runtime-Classes is already solved.
    What remains is, that these Classes (which provide the necessary Abstraction-Layer for platform-independence of VB6-Code written "on top"),
    are used (to produce the new Compiler and new IDE).

    Olaf
    What you're describing here actually isn't VB6. This is an entirely different development platform. All VB6 provides is the IDE and the compiler. You won't be writing VB6 apps, you're actually writing RC5 applications. What you've described here is what MS actually did with VB.Net. They used the BASIC language on top of a framework, in your case it, the framework is RC5.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  27. #27
    PowerPoster Arnoutdv's Avatar
    Join Date
    Oct 2013
    Posts
    5,872

    Re: Is the VB6 community capable to grab the bull by its horns?

    But then in the end it is a new language with new features and maybe the same syntax.
    Cross platform sounds like a huge step forward, but in my situation this means I have to rewrite my entire GUI .
    Most GUIs in VB6 use normal forms with the basic VB6 controls and often a lot of external ActiveX controls.
    Rewriting this is an massive operation. In which case you can ask yourself why not choose some other development platform.

    Just my 2 cents.

  28. #28
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by Arnoutdv View Post
    But then in the end it is a new language with new features and maybe the same syntax.
    Cross platform sounds like a huge step forward, but in my situation this means I have to rewrite my entire GUI .
    Most GUIs in VB6 use normal forms with the basic VB6 controls and often a lot of external ActiveX controls.
    Rewriting this is an massive operation. In which case you can ask yourself why not choose some other development platform.

    Just my 2 cents.
    And we have arrived back to the original problem that arose when MS stopped development of VB6 in favor of .Net. which is the lack of a clear and painless migration path. What all this tells me is that in the end, Microsoft knew what they were doing because in your efforts to keep VB6 alive, you ended up on the exact same path they went on all those years ago. The path that leads to something that only resembles VB6 but is far from being VB6.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  29. #29
    Fanatic Member
    Join Date
    Jun 2019
    Posts
    557

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by Niya View Post
    What you're describing here actually isn't VB6. This is an entirely different development platform. All VB6 provides is the IDE and the compiler. You won't be writing VB6 apps, you're actually writing RC5 applications.
    That is what I was going to write. And what I am trying to explain in few posts in this subforum, also in this thread.

    Basic (and VB as just another Basic variant) as language is one thing. The platform/tech stack is something completely different. VB6 + RC5 is not compatible with my VB6 + 20-25 years of messy coding of tens of developers with unlimited references to random libraries and 3rd party COM objects + my own contribution to the mess with mixed .NET 3.5/4/4.5/4.61/4.8 bloat of "helper" libraries, tools and total nightmare of used tech. It is quite hard to get everything compiled even with VB6 and requires a lot of internal docs how to setup everything step by step and it is still hard to get it working from first time.

    In another thread I wrote about expectations. 100% compatibility of old code without any refactoring is not possible. Not for the price of wasted time and effort, and still will have chance of fail to compile projects.

    Olaf, I hope more people will read carefully what you wrote, as the expectations are really wrong most times.

  30. #30
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by Niya View Post
    What you're describing here actually isn't VB6.
    I disagree.

    Since we talk about a new compiler ... VB6 is a first and foremost a language, which was made to primarily:
    - glue COM-libs together
    - but also to produce ones own COM-libs the easy way

    And the new RT-Classes (contained in the RC6-libs) are already providing these COM-Objects,
    which the normal VB6-IDE is capable to "glue together" - using intellisense and COM-introspection
    (as demonstrated in hundreds of examples - e.g. here in the Code-Bank).

    Quote Originally Posted by Niya View Post
    This is an entirely different development platform.
    No, it is the exact same VB6-IDE - everyone is used to already - which allows to glue these new RT-Objects together.

    Quote Originally Posted by Niya View Post
    All VB6 provides is the IDE and the compiler.
    Sure - and a new Compiler will only need to support COM-Classes, to be able to make use of the new Runtime-Objects.

    Quote Originally Posted by Niya View Post
    You won't be writing VB6 apps, you're actually writing RC5 applications.
    You may call these Apps whatever you want - but here's the facts:
    - a VB6-App which only has a reference to the RC6-lib
    - will already be written in a platform-portable manner
    - and later recompileable without any code-changes with the new compiler (e.g. for Win64 and Linux64)
    ..(the new compiler would even support static linking of only the used RC6-Classes into a given target-Binary)

    Make no mistake - I'm talking about "normal VB6-Code" here (which runs in the old VB6-IDE - but also in the new IDE+Compier) -
    so I don't see, why the Apps produced this way, shall not be called "VB6-Apps".

    As for GUI-compatibility (with regards to existing *.frm and *.ctl files) - these should be relatively easily translatable to RC6-GUI-Widgets,
    via proper Import-Modules.

    I've demonstrated this already in a Demo (posted here into some Forum-Thread), which translated a normal *.frm File
    (which contained all kinds of Intrinsic-Controls) "on the fly" to appropriate RC6-Widgets.

    And since we are at it now - this (for me), is the part where the community could contribute quite a bit
    (writing these *.frm to RC6-Widgets Importer-Modules), to be able to later on lift entire "old-style-GUI" Projects over to the new platform.

    Olaf

  31. #31
    PowerPoster
    Join Date
    Feb 2015
    Posts
    2,672

    Re: Is the VB6 community capable to grab the bull by its horns?

    Although I do not like to participate in holiwar topics, I will say a few words.

    VB7 should provide the backward compatibility with older projects. Therefore, it must have the same concept as the original VB6 - be based on/native support COM/ActiveX and be RAD as VB6. There is no other language with this concept so there is no replacement for VB6.

    About requirements for a new VB. It should be the same VB6 as we have so we have the starting point where we can improve it (for example add MTA support/64 bit compiler/etc) without breaking the backward compatibility.

    How to break the task? Just use the original VB6 and replace it piece by piece. You can test parts without have a complete project. For example, the first part - full compatible P-code virtual machine. So when it'll be done you can replace the original code in vba6/msvbvm60 to test it. The only problem here is that it requires reverse engineering, so few people can develop new compiler. Anyway you can always ask me i have some undocumented information which i got by researching runtime.

    The last thing of course is the time/money. Nobody will do VB7 for free because it's very difficult project.

    Just my 2 cents.

  32. #32
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by peterst View Post
    ...language is one thing. The platform/tech stack is something completely different.
    Exactly - but a modern and well-written platform/tech stack is necessary (underneath any new language, when it shall have any chance of success).

    The RC6-lib provides such a stack already.
    And this stack (the Runtime-Classes it provides) already adhere to at least a well-defined, standardized ABI (COM) -
    which plays well together with the existing VB6-IDE - but also with a potential new one (when the compiler comes with COM-support - which e.g. TwinBasic claims to have).

    Quote Originally Posted by peterst View Post
    VB6 + RC5 is not compatible with my VB6 + 20-25 years of messy coding
    Right - but as written in my prior post -
    your old "messy VB6-Code" can be made to work within the new environment, via *.frm import-modules:
    - as long as these Importer-Modules support the Intrinsic VB6-Controls (CommandButton, Labels, TextBoxes, List- and ComboBoxes, Check- and OptionBoxes).
    - this Importer could be enhanced successively, to support later on also the stuff from the CommonControls ("ToolBars, ListViews, TreeViews, MonthViews", etc.).

    This (*.frm-Importer-Modules) is the only "clean" way, to address the problem of:
    - "a new, modern - DPI-aware and Alpha-capable GUI" (which everyone wants in his checklist for a VB6-successor)
    - and the problem of "64Bit-ness of new GUI-Controls", which will also work platform-independent (depending only on a compiler-switch)


    Quote Originally Posted by peterst View Post
    ... unlimited references to random libraries and 3rd party COM objects
    Yep - these "random Control-libs" exist - and for most of them there will not be matching "Importer-Code"
    (which then maps them automatically to existing "native-Widgets").

    But wasn't one of the "fix-points of a new Compiler" the 64Bitness?
    I hope you are aware, that most of these older "random Control-libs" are not existing in a 64Bit-version
    (and thus, old VB6-Projects which contain them, will not be compilable to 64Bit).

    And again - here my main-argument:

    Eduardo already calculated "several man years of work, still to do".

    Now, what do we want to invest these man-years into?

    1) A Windows-only version, which will:
    - not be able to translate every old project (due to missing 64Bit-versions of Controls and other dependency-libs).
    - huge amounts of new IDE-Code which will never be platform-portable, because of using GUI-libs and interfaces which are only available on Windows

    2) A (from the get-go) multiplatform-capable IDE+Compiler, that was based on a modern RT-ClassLib, wich will:
    - require less GUI-Code to write, compared with the Windows-version (less man-hours, until the new IDE is finished)
    - be able to produce 32- and 64Bit binaries for any platform (including the GUI)
    - not be able to translate every old project (due to missing Widget-Mappings in the *.frm Importer-Modules)

    Olaf

  33. #33
    Frenzied Member
    Join Date
    Aug 2020
    Posts
    1,421

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by Schmidt View Post
    In my opinion, anything "Visual-IDE-like" which is not developed against platform-independent (GUI-)libs from the get-go,
    will not survive long-term.
    I totally agree with you. Before your new compiler comes out, I hope to achieve cross-platform through a new scripting language.

    Quote Originally Posted by Arnoutdv View Post
    But then in the end it is a new language with new features and maybe the same syntax.
    Cross platform sounds like a huge step forward, but in my situation this means I have to rewrite my entire GUI .
    Most GUIs in VB6 use normal forms with the basic VB6 controls and often a lot of external ActiveX controls.
    Rewriting this is an massive operation. In which case you can ask yourself why not choose some other development platform.

    Just my 2 cents.
    Yes. I considered this a few years ago. RC5.vbWidget is an excellent GUI library, but its usage is completely different from MS-CommonControls, which will make many people give up migrating to RC5. I once planned to use RC5 to rewrite Krool's CommonControls and FlexGrid, but this plan was abandoned for multiple reasons. But I always think that it's necessary to rewrite Krool's CommonControls and FlexGrid with RC5/RC6, and ColinE66 should be the best candidate for this job.

  34. #34
    Fanatic Member
    Join Date
    Jun 2019
    Posts
    557

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by Schmidt View Post
    ...
    Yep - these "random Control-libs" exist - and for most of them there will not be matching "Importer-Code"
    (which then maps them automatically to existing "native-Widgets").

    But wasn't one of the "fix-points of a new Compiler" the 64Bitness?
    I hope you are aware, that most of these older "random Control-libs" are not existing in a 64Bit-version
    (and thus, old VB6-Projects which contain them, will not be compilable to 64Bit).
    I am very aware, but other people are not. That is what I am trying to explain in few threads I wrote and (again) the expectations.

    Quote Originally Posted by Schmidt View Post
    Now, what do we want to invest these man-years into?

    1) A Windows-only version, which will:
    - not be able to translate every old project (due to missing 64Bit-versions of Controls and other dependency-libs).
    - huge amounts of new IDE-Code which will never be platform-portable, because of using GUI-libs and interfaces which are only available on Windows

    2) A (from the get-go) multiplatform-capable IDE+Compiler, that was based on a modern RT-ClassLib, wich will:
    - require less GUI-Code to write, compared with the Windows-version (less man-hours, until the new IDE is finished)
    - be able to produce 32- and 64Bit binaries for any platform (including the GUI)
    - not be able to translate every old project (due to missing Widget-Mappings in the *.frm Importer-Modules)

    Olaf
    Very hard choice for people who want to compile every old project, as there is no third option (100% compatible without any modification). And there will be no such option for many reasons*

    For me the choice is already done but it is not part of this discussion.

    * Last days I've been digging into some .NET runtime libraries source and there were some comments about keeping the code as is for compatibility reasons, even it is buggy and some functions return wrong results. This is the legacy for 20 years of .NET development. And it is the same for VB6 - 100% compatible means to include bugs and wrong behavior

  35. #35
    Frenzied Member
    Join Date
    Aug 2020
    Posts
    1,421

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by Schmidt View Post
    Exactly - but a modern and well-written platform/tech stack is necessary (underneath any new language, when it shall have any chance of success).

    The RC6-lib provides such a stack already.
    And this stack (the Runtime-Classes it provides) already adhere to at least a well-defined, standardized ABI (COM) -
    which plays well together with the existing VB6-IDE - but also with a potential new one (when the compiler comes with COM-support - which e.g. TwinBasic claims to have).


    Right - but as written in my prior post -
    your old "messy VB6-Code" can be made to work within the new environment, via *.frm import-modules:
    - as long as these Importer-Modules support the Intrinsic VB6-Controls (CommandButton, Labels, TextBoxes, List- and ComboBoxes, Check- and OptionBoxes).
    - this Importer could be enhanced successively, to support later on also the stuff from the CommonControls ("ToolBars, ListViews, TreeViews, MonthViews", etc.).

    This (*.frm-Importer-Modules) is the only "clean" way, to address the problem of:
    - "a new, modern - DPI-aware and Alpha-capable GUI" (which everyone wants in his checklist for a VB6-successor)
    - and the problem of "64Bit-ness of new GUI-Controls", which will also work platform-independent (depending only on a compiler-switch)




    Yep - these "random Control-libs" exist - and for most of them there will not be matching "Importer-Code"
    (which then maps them automatically to existing "native-Widgets").

    But wasn't one of the "fix-points of a new Compiler" the 64Bitness?
    I hope you are aware, that most of these older "random Control-libs" are not existing in a 64Bit-version
    (and thus, old VB6-Projects which contain them, will not be compilable to 64Bit).

    And again - here my main-argument:

    Eduardo already calculated "several man years of work, still to do".

    Now, what do we want to invest these man-years into?

    1) A Windows-only version, which will:
    - not be able to translate every old project (due to missing 64Bit-versions of Controls and other dependency-libs).
    - huge amounts of new IDE-Code which will never be platform-portable, because of using GUI-libs and interfaces which are only available on Windows

    2) A (from the get-go) multiplatform-capable IDE+Compiler, that was based on a modern RT-ClassLib, wich will:
    - require less GUI-Code to write, compared with the Windows-version (less man-hours, until the new IDE is finished)
    - be able to produce 32- and 64Bit binaries for any platform (including the GUI)
    - not be able to translate every old project (due to missing Widget-Mappings in the *.frm Importer-Modules)

    Olaf
    IMO, it is unrealistic for many VB6ers who are used to MS Common Controls to use RC5.vbWidgets. I think a more feasible way is to use RC5/RC6 to rewrite Krool's CommonControls and FlexGrid, and then give these fully compatible RC5 controls to others to use.

  36. #36
    Fanatic Member
    Join Date
    Jun 2019
    Posts
    557

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by SearchingDataOnly View Post
    RC5.vbWidget is an excellent GUI library, but its usage is completely different from MS-CommonControls, which will make many people give up migrating to RC5. I once planned to use RC5 to rewrite Krool's CommonControls and FlexGrid, but this plan was abandoned for multiple reasons. But I always think that it's necessary to rewrite Krool's CommonControls and FlexGrid with RC5/RC6, and ColinE66 should be the best candidate for this job.
    Isn't that the problem with the "migration" to VB.NET? Even WinForms is the nearest form to what VB6 forms are. I am not even talking about WPF and UWP, where the learning curve is much higher.

    Yes, RC6 GUI widgets, WinForms, WPF, UWP, choose anything that is not drag and drop from toolbox to the form, will scare people and they will say: "But this is not VB6!"

    So what is the answer to all expectations for VB6 100% compatible compiler? Don't expect that. Take a deep breath and dive into another language, framework, library or tech stack.

  37. #37
    Frenzied Member
    Join Date
    Aug 2020
    Posts
    1,421

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by The trick View Post
    The last thing of course is the time/money. Nobody will do VB7 for free because it's very difficult project.
    Yes, time and money are the two biggest problems. However, it's impossible to directly make money with VB7 (if VB7 is not a free language, it's difficult to obtain large-scale applications and promotion). The most feasible way is to use VB7 to develop a large number of new excellent desk-apps and web-apps, through these apps to make money to support the further development of VB7, which is why I say that a "software ecological chain" must be formed.

  38. #38
    The Idiot
    Join Date
    Dec 2014
    Posts
    2,721

    Re: Is the VB6 community capable to grab the bull by its horns?

    what The trick is posting is exactly the procedure.
    replace one part at a time and see if its working.

    and as he is saying this would require a kickstarter or patron for the coders in charge of this project, that could take years to complete, so this need time and patience and support.

    of course google can be used, if theres someone out there that has already done some work,
    like this one: https://github.com/cocus/openmsvbvm/...ter/openmsvbvm
    is it legit? something that can be used?

    this site, interesting? http://sandsprite.com/vb-reversing/

  39. #39
    Frenzied Member
    Join Date
    Aug 2020
    Posts
    1,421

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by peterst View Post
    Isn't that the problem with the "migration" to VB.NET? Even WinForms is the nearest form to what VB6 forms are. I am not even talking about WPF and UWP, where the learning curve is much higher.

    Yes, RC6 GUI widgets, WinForms, WPF, UWP, choose anything that is not drag and drop from toolbox to the form, will scare people and they will say: "But this is not VB6!"

    So what is the answer to all expectations for VB6 100% compatible compiler? Don't expect that. Take a deep breath and dive into another language, framework, library or tech stack.
    What I understand is that "100% compatible with VB6 compiler" refers to the "100% compatible with VB6 syntax" (that is 100% compatible with VB6-Class and VB6-Module), not to say that the old VB6 GUI projects can Migrate to VB7 completely automatically.

    However, if Krool's Common Controls can be rebuilt with RC5/RC6, then the old VB6 GUI projects can be migrated to the new VB7 at a very low cost.

    In addition, in my opinion, the main value of the new VB7 is reflected in:
    (1) Cross-platform
    (2) 64-bit
    (3) More convenient and simple to develop Desk-Apps, Web-Apps and Mobile-Apps

    So, migrating the old VB6-GUI projectss is not the main purpose of VB7.

  40. #40
    Frenzied Member
    Join Date
    Aug 2020
    Posts
    1,421

    Re: Is the VB6 community capable to grab the bull by its horns?

    Quote Originally Posted by baka View Post
    what The trick is posting is exactly the procedure.
    replace one part at a time and see if its working.
    When using RC5 components to gradually replace MS Common Controls, it's actually performing "replacing one part at a time and see if its working"

    It's 5 am, and I haven't slept all night. Good Night.

Page 1 of 5 1234 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width