Page 2 of 4 FirstFirst 1234 LastLast
Results 41 to 80 of 136

Thread: VB Classic (A True VB 7.0)

  1. #41
    Junior Member
    Join Date
    Aug 2011
    Posts
    28

    Re: VB Classic (A True VB 7.0)

    As for me, I hope:
    step 1. develop the vb7 compiler that can compile the old vb6 .cls and .bas to a console .exe file, as possible as VB6 language compatible. the compiler can run on linux and windows, maybe can based on llvm. this step no need support ui controls files such as .frm or .ctl files. but need develop the file and network and other no-ui class library that needed by the ui-controls, all these library file are .cls and .bas file.
    step 2. develop the vb7 controls with the same names as the old vb6, the vb7 controls can based on vbRichClient or wxWidgets or qt or others. the controls need can compiled use the compiler developed in step 1.
    step 3. develop the vb7 compiler that can compiler the old vb6 .frm and .ctl and .res files use the controls developed on step2, after this step, all the vb6 projects that didn't use the activex controls can be compilered and run on linux and windows.
    step 4. develop the vb7 compiler that can support activex control on windows, to do as possible as VB6-compatible on windows.
    step 5. develop the vb7 IDE that only use the controls develop in step2, then the vb7 ide can run on windows and compile old vb6 project, and the ide can open the vb6 projects on linux.
    Then, all my vb6 project can opened on the new vb7 ide and can compiled and run on window. And on linux need do some modify to compiled and run on linux, so can move all my vb6 projects slowly from windows to linux.
    Last edited by mjohnlq; Aug 24th, 2013 at 05:20 AM.

  2. #42
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB Classic (A True VB 7.0)

    Whoaa, too many replies to answer them all "as carefully" as I did before - so please forgive me, when in the following I will "brush over it"
    in a fast (and rough) way - please don't take anything personally - I just want to make my position more clear, even if it "hurts" somebody.

    So here my "staccato answers" to the postings in the order they came up:

    @dee-u:
    > "When are you guys going to end the discussions and start working on this?"

    Good point - let's stop talking - either you help - or you don't (well - and I note from your wording above, that you don't count yourself among the helpers)


    @sten2005:
    > "Your view seems to be the same as that of Microsoft when they brought out Vb.Net. "Move to our shiny new language(package) - but your legacy code is your problem".
    > "That didn't persuade VB6 developers to move to VB.Net and it won't persuade them to move to VB7 either."

    To make it short - I don't care who is "persuaded to move to it later when its finished" (since that doesn't help me much with the problems at hand) ...
    VB6 is still entirely sufficient for many things - and so there's apparently not much real pressure on the VB6-devs - later if that pressure increases in the future,
    then those developers will start looking for alternatives - and I hope that (among the different choices, which are then available in 5-10 years time),
    that VB7 stands out with a compiler which is the most compatible to the VB6-language - and with an IDE which is also very familiar, and with native Widget-Controls
    which look and feel familiar too.


    @WhyWontIEdieAlready (Dominik)
    > if it does not turn up, could you at least post the essence of your thoughts?

    I've explained my plans, how to achieve component-model-libs which offer selfdescribing classes -
    and that I think I can manage this in a way which is rather compatible to COM - though still remains platform-portable.
    So, for COM-Dlls there is a high probability that access to COM-classes will be available - though OCXes are interface- and
    also siting-wise an absolutely over-engineered and complex thing MS cooked up there - and I'm not willing to support this
    clumsy approach directly in the new language-runtime and the compiler - the new Widget-concept is based on just two
    interfaces - "just a normal class", and siting-wise also totally easy to handle (and will be fully platform-portable).

    That was basically the essence of the technical background.

    > "Contrary to dee-u I think this is an important discussion - event though it's a topic that got heated rather quickly."

    It is - those who are about to invest time (which apparently is not dee-u's intention) deserve a little bit of a "roadmap-explanation"
    and where the whole thing is supposed to end up.

    > "Also, for the record, I think that even a VB7 without support for OCX-Controls and Active-X-Dlls would be a good thing, "
    Yep, the full *.cls and *.bas support alone should everybody "make dancing with joy" here (at least, so I thought) -
    and as said, ActiveX-Dlls will very likely be supported - because that's not really difficult - when the Class-concept of the
    new compiler is pretty compatible to the COM-base interfaces and appropriate VTable-structures and -behaviours.


    > "but it does not seem to be a viable option for a lot of existing projects. But from my standpoint it would not help my current situation that much without said support."
    As said, your current situation is not really "dire" - you have a well enough working VB6 still.

    The question I was asking you in my lost posting (and also sten2005, but he didn't care to answer it) was:

    "What do you expect from a VB7, which VB6 cannot offer to you these days too."

    And for my part I answered it with:
    First and foremost: platform-independence, a community-based source-base nobody can take away "from us" in the future - and VB6-code-compatibility.
    (and a few other things of course, but those are secondary).

    VB7 shall be (in my thinking) a tool which "nobody is able to break anymore" - but if it ties itself (with its runtime-roots) too deeply to MS-approaches one can find only on the
    Win-platform, then we loose that strongest of its features - that's why OCX-support is entirely secondary in my thinking - if there's enough contributors for that, then it
    will come later in a sideward-docking approach, which is offered in addition to the Runtime-supported NativeWidgets (nothing is impossible to accomplish, binding-wise - with a C-compiler in the backend).

    > "I am also not sure why you think that OCX/ActiveX support is a bad idea. Yeah, it may break in the future, but it would help with converting projects today."
    Those projects would (after conversion) break in the same way as when you'd have left the OCXes in your VB6-project - I still don't understand, why nobody sees the logic behind that.

    If you port something, then port it decently (in a way that will not break in the next 10 years at least).

    A tool which will offer both: platform-independence over its native Widget-concept, but also full compatibility to OCXes and older VB6-Controls -
    that's asking too much from a community-project with (yet) limited man-power.
    Let's finish the first round - see where we end up (and how large the team is at that point in time) - then move further and decide which
    additional features go up or down on the priority-list.

    > "Let's compare:"
    > "VB.NET does support OCX/ActiveX DLLs but did not support an easy way to port the source without major code changes."
    > "The VB7 you suggest would allow easy porting of code but would not allow OCX/ActiveX integration."

    Well, you forgot: VB6 offers full support for OCXes/AXDlls and is fully compatible to VB6

    > "Both is a big problem for me. "

    And why is that - please ask yourself truly, why it comes, that you consider that a big problem.
    Is it not the fear, that MS will break something in the future, which will render VB6-Apps useless?

    I can only tell you again - if that your fear was well-founded and MS will break something that renders VB6-apps useless,
    then a highly compatible designed VB7-compiler, which offered fulll OCX-support will be broken too.

    What you could think about instead is: what tools can make such a potential future breakage more bearable (with the least over-all-efforts)?

    And when there's something out there, which has "we will be unbreakable" written in bold letters all-over its flag -
    and is nearly fully VB6-code-compatible - wouldn't that project worth a thought from your end - would it be worthy of your support?


    > "So, yeah I think VB7 is a good idead - event without OCX/ActiveX support.

    Thanks - thought so too.

    > "But wihtout that support it would sadly be not an option for me (and I think for a significant number of other developers).

    Currently, yes - but I explained just that a few lines above - so let's wait for the VB6-breakage.


    > "I still would appreciate it and certainly would have a look and maybe start new projects in VB7 because having an open source IDE/Framework/compiler for a langauge I am more than familiar with is still a good thing "

    Exactly, an "open source IDE/Framework/compiler for a language one is familiar with is a good thing"...
    though somehow I have the feeling - that you still consider the whole idea as "a product" - and yourself "a customer" - and that
    "announcing to not buy the product" (in a kind of "customer is always king"-fashion) will achieve something ... IMO this is not the case.

    In a community-project which lives from the efforts of contributors - the only thing what counts is the input those people give.
    If you are among them, then your opinions have more weight - you could show (per code-contribution) if an idea of yours is worthwhile.

    > "As I see it: If we had VB7 with OCX/ActiveX support we could port our projects now and hopefully enough 3rd party developers would support that system natively

    No - nothing would happen then (without having a kind of soft-pressure, which will encourage the writing of Widgets instead of OCXes) .

    Olaf

  3. #43
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by mjohnlq View Post
    As for me, I hope:
    step 1. develop the vb7 compiler that can compile the old vb6 .cls and .bas to a console .exe file, as possible as VB6 language compatible. the compiler can run on linux and windows, maybe can based on llvm. this step no need support ui controls files such as .frm or .ctl files. but need develop the file and network and other no-ui class library that needed by the ui-controls, all these library file are .cls and .bas file.
    step 2. develop the vb7 controls with the same names as the old vb6, the vb7 controls can based on vbRichClient or wxWidgets or qt or others. the controls need can compiled use the compiler developed in step 1.
    step 3. develop the vb7 compiler that can compiler the old vb6 .frm and .ctl and .res files use the controls developed on step2, after this step, all the vb6 projects that didn't use the activex controls can be compilered and run on linux and windows.
    step 4. develop the vb7 compiler that can support activex control on windows, to do as possible as VB6-compatible on windows.
    step 5. develop the vb7 IDE that only use the controls develop in step2, then the vb7 ide can run on windows and compile old vb6 project, and the ide can open the vb6 projects on linux.
    Then, all my vb6 project can opened on the new vb7 ide and can compiled and run on window. And on linux need do some modify to compiled and run on linux, so can move all my vb6 projects slowly from windows to linux.
    Your list above favours a "compiler first, then everything else"-approach.

    I've already explained why I don't think that to be a good idea in my very first post in this thread.

    There exist already well-working basic-compilers (developed in a non-integrated, standalone-fashion) as FreeBasic and OxygenBasic.

    Especially FreeBasic does exist now for a few years already - and so far there is no well-integrated IDE-concept in sight,
    which offer something like VBs UserControl-designer (so that you can design your own Controls/Widgets).
    Also Edit&Continue is not addressed in any way (Debugging support in the existing IDEs for FreeBasic is very limited).

    So there you can study already "a case" where a "standalone-compiler-first, IDE and GUI-bindings later" approach was failing
    (despite a relatively large community).

    If we want to come up with a tightly integrated, "Visual Environment" - then we will have to build this thing around
    an IDE - and integrate the compiler there in a way, which interacts in the same fashion as VB6 with the Editor-Window
    (pre-compiling the current line after you move the cursor away from it in the Editor) ... we will need to try already in the
    very basic first compilation-tests an integration of the Debugger-Handling and an Edit&Continue concept which interacts
    visually with the Editor-Pane and the watched variables.
    We need to do that early, as long as things in the compiler and Editor are still simple - if we start an attempt later when
    the compiler is already in an advanced state - I foresee larger problems to integrate something like that successfully and
    as deeply as we have it available in the VB6-IDE currently.

    That said - in case you are the author of the llvm-based approach here:
    https://code.google.com/p/extended-b...extended-basic

    I'd like it really much, when you would join the team.

    Olaf

  4. #44
    PowerPoster
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    2,412

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Schmidt View Post
    Yes, that's easy enough with "forking a GitHub-Repo online" (into your own. previously created GitHub-account, which you can maintain and change against your local HardDisk independently).
    If you have "nice changes to contribute", then start a "Pull-Request" - (such Requests become visible on the GitHub-WebPage of the originator-Repo - and can be commented on - and later on
    merged into the main-branch ... thereby fulfilling this "Pull-Request" of the contributor with a "Merge-Response", so to say).
    I've started contributing to the vbWidgets project on GitHub. While I use Git for my own projects, I'm the only developer which makes it easy to have my own "protocol" for submissions. I hope I've followed the proper protocol for your project, but please let me know if you would like things done differently.


    Regarding the controversy as to whether to support OCXs, it has become a polarizing issue.

    Do you see a path where the IDE can be developed to support a plugin extension that could offer some kind of OCX support (perhaps in a container widget that bubbles events up to the new form engine). This would allow a second group of interested parties to spend effort developing OCX support, while the rest of the team that doesn't really care for it can ignore those efforts and work on the rest of the IDE.

    This would also help to entice VB6 developers over who think they need OCX support, and introduce them to the new IDE and new features of framework. While they get comfortable with the new environment, over time they could migrate their apps completely off the OCXs and gain full cross platform, 64-bit, unicode, etc... functionality.

  5. #45
    New Member
    Join Date
    Aug 2013
    Posts
    8

    Re: VB Classic (A True VB 7.0)

    @Schmidt

    First of all: Thanks for taking the time to answer my post again!

    I for one are not put off by your tone or take this personal because I think it is quite natural that a discussion about a topic several people have strong opionions about get's a little heated. A controverse discussion does not mean that I cannot respect other peoples views. Quite the oppisite: I really want to understand the different approaches and opinions, because I think it's a topic that deserves some real effort.

    To clarify: I do have some knowledge about the component object model and TLBs and stuff, but I am by far no expert. I am able to query COM interface in source, call functions, use properties by name in code and stuff but I did not know that OCX Controls and ActiveX Dlls are from a technical standby a big difference in complexity. Thanks for putting it into some kind of perspective.

    The support of ActiveX DLLs would make the proposed system a lot more interesting. I know this sounds again like a customers perspective. But I absolutly respect that this project - if it would be realized - would only be possible through hard work of a small team of very invested developers and that it would be crazy to "demand" anything from them. But I also think that it would be very good to have a broader base of support right from the start so that there are a lot of devs who - event if they cannot contribute directly - could help test the IDE, find bugs, promote the new system to other developers etc.

    And like myself I am sure a lot of them need to see a viable approach for existing projects. You are kind of right when you write that the best VB6-compatible language today is VB6. But my point ist the following: I do have the fear that Microsoft may be one day stupid enough to break VB6 support and I do want to port our applications to another system before this happens. But this conversion also has to be affordable in terms of time and money. The support ActiveX-DLLs you said could be an possible without too much hassle would help a great deal: With something like this (source compatible + ability to use ActiveX-DLLs) I for one would be willing to port our software. Without OCX support this would still cost for our main application alone something around 750 hours of developer time (raw estimate of course), but at least that would be affordable (compared to around 2.500 hours). But this is just us. Other developers might have a different situation where they simply cannot afford to port without OCX support. I am sure most if not all of them would LIKE to though. I know that if Microsoft breaks support eventually I would still have to port the rest, but at least I would not need to do this all at once (which I cannot afford) but step-by-step (which I could afford).

    If there was ActiveX-DLL support, that would really help out a lot of developers.
    If there would be OCX support that would attract a whole lot of other developers to support the project (in some way or another)

    This is why I am so interested in this aspect and persistent to "fight" for it ;-)

    Regarding myself I would love to help out a project like this in any way I can - I do not think of this as a product and understand very well how much effort this thing would cost. However I do not know of how much help I could be given that I am mostly an application developer with some basic knowledge about compilers. What I AM good in would be: Helping develop a good framework library, developing and fine-tuning the IDE, helping to achieve a good user-experience, coming up with creative solutions, write widgets, help with translation, deliver graphics and contribute to language features (in my career I have developed about a dozen or so scripting languages for various plattforms and target groups).

    Regarding the road map: I agree with you that the IDE and especially Debugging and Edit & Continue are essential key elements and need to be addressed right from the start. E&C in VB6 is still today one of the best regarding ease of use and performance.

    Dominik

  6. #46
    New Member
    Join Date
    Aug 2013
    Posts
    8

    Re: VB Classic (A True VB 7.0)

    @schmidt

    Here are some suggestions for a compromise for OCX controls based on your suggestion for a VB7:

    When opening a VB6 project the IDE will have to do some sort of conversion (to transfer intrinsic VB forms & controls to the new widget system), right?. A good approach could be to program the converter to use conversion manifests for different control types so that a developer could add their own conversion manifests to convert other controls as well. That would help with all OCX Controls that only add optical value (like better looking buttons etc.) and already have a replacement that offers the same functionality but in incompatible form. The conversion file would include mappings for properties, events, etc. and should have the ability to contain VB code in itself to help with more complicated stuff.

    Here is an example:

    MyCrazyCustomButton.occ:

    Code:
    Public PropertyMappings as new cMap = (
        Text => Caption
        TextColor => ForeColor
    )
    
    Public EventMappings as new cMap = (
        DoubleClick => DblClick
    )
    
    Sub HandleProperty(Byval pPropertyName As String, Byval pAssignedValue, Byval pWidgetContext AS cWidgetContext)
        Select Case pPropertyName
            Case "Theme"
                If pAssignedValue = "iThemeWarning" Then
                    pWidgetContext.SetProperty("BackColor", Rgb(255,0,0))
                    pWidgetContext.SetProperty("ForeColor", Rgb(255,255,255))
                    pWidgetContext.SetProperty("Icon", "Icons\wa
                Else
                    [...]
                End If
        End Select
    End Sub
    [...]
    Another helpful conversion tool would be the ability to auto-generate widget templates based on used OCX controls that do not have a conversion manifest: If the import assistant stumbles upon a control it checks the availability of a conversion manifest (which could even be used for intrinsic VB controls to minimize hard coded conversion routines). If none is found it queries the controls' interface and generates a dummy widget with all the needed properties, methods, functions and events to start writing a replacement. This "dummy" would ensure that the conversion can be completed and can be used as a temporary placeholder or a good starting point to write a custom replacement.

    Dominik

  7. #47
    New Member
    Join Date
    Aug 2013
    Posts
    8

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Schmidt View Post
    The question I was asking you in my lost posting (and also sten2005, but he didn't care to answer it) was:

    "What do you expect from a VB7, which VB6 cannot offer to you these days too."

    And for my part I answered it with:
    First and foremost: platform-independence, a community-based source-base nobody can take away "from us" in the future - and VB6-code-compatibility.
    (and a few other things of course, but those are secondary).
    Sorry, I posted a whole lot of stuff and DID forget to answer the question ;-)
    So here it comes:

    I would love to see the following features in a VB7 today:
    - I like the open-source aspect very much, but would -to be honest- also settle for a commercial product if they would still respect their customers and would offer a good support
    - The ability to attract younger developers that currently do not want to invest time in a "dead language"
    - A bug-fixed IDE with some new comfort features (but not a bloated one like VS is offering - I rather like it fast & slick!)
    - Some enhancements regarding the language itself to help dealing with larger projects: Better inheritance, easier syntax for optional parameters, small stuff like that - but it would make a big difference in terms of efficiency
    - Platform independence (because in my humble opinion and strictly professional speaking Windows 8 Modern UI plain s*cks)

    Dominik
    Last edited by WhyWontIEdieAlready; Aug 24th, 2013 at 01:51 PM.

  8. #48
    New Member
    Join Date
    Aug 2013
    Posts
    8

    Lightbulb Re: VB Classic (A True VB 7.0)

    @schmidt

    Sorry for posting so much, but I think I just found a simple solution to provide an OCX bridge widget based on your vbRichClient framework:

    It's pretty simple: We could develop a tool to automatically create a widget-wrapper for any given OCX Control. This tool could even be integrated in the import assistant, so that importing a VB6 form would work like this:

    - Check if there is a conversion manifest (for intrinsic controls and other controls that already have a valid replacement)
    - YES: => Convert to new widget
    - NO: => Create wrapper widget and compile it automatically using the old VB6 compiler (that is needed for the wrapper creation, not for the later runtime) and use the wrapper

    How the OCX wrapper widgets works and why it will work with your system as long as Windows supports the VB6 runtime including thunderforms:

    - It's simply a widget in your format, it's just an ActiveX DLL component
    - Compiling the wrapper will require VB6.exe / C2.exe since it uses a thunderform as a host for the wrapped OCX control
    - In runtime it does only require VB6 runtime support of the target operating system (Wine + Windows up until Microsoft pulls the plug)
    - When connecting to the parent by the "AddedToHierachy" event it will dynamically create a thunderform and dynamically add the control
    - The Win32 API command "SetParent" is used to make the form a child of the parent form (accessing it's hwnd over your widget architecture)
    - If the base widget is moved, shown, hidden, resized so is the form and the wrapped control
    - If the widget is removed the Form will be removed with SetParent Form.hwnd, 0 and the hosted OCX control will be destroyed
    - All events, properties and methods of the hosted OCX control will be mapped and be made accessible without direct access to the wrapped object and therefore there is no need to support the VBExtenderObject on the side of your framework - just Events, Methods, Properties

    We could event write a universal OCXWrapper that can basically add every OCX dynamically to a form based on the vbRichClient framework by creating it via Form.controls.add("Server.Control", "Name", Form), accessing it's events dynamically by using the VBExtenderObject and making it's properties and methods available by using the "InvokeHookArray" method of the TypeLibe Information Library (TLBINF32.dll).

    Here is a proof-of-concept (without properties and methods, but that is guaranteed to work because I already tried this in another project of me where my own scripting language can bind ActiveX-Dlls and create the COM-objects located within):

    fOCX.frm
    Code:
    VERSION 5.00
    Begin VB.Form fOCX 
       BackColor       =   &H0080C0FF&
       BorderStyle     =   0  'Kein
       Caption         =   "Form1"
       ClientHeight    =   3150
       ClientLeft      =   0
       ClientTop       =   0
       ClientWidth     =   4680
       LinkTopic       =   "Form1"
       ScaleHeight     =   3150
       ScaleWidth      =   4680
       ShowInTaskbar   =   0   'False
       StartUpPosition =   3  'Windows-Standard
       Begin VB.CommandButton but_SelfDestruct 
          Caption         =   "Destroy"
          Height          =   315
          Left            =   0
          TabIndex        =   0
          Top             =   0
          Width           =   1275
       End
    End
    Attribute VB_Name = "fOCX"
    Attribute VB_GlobalNameSpace = False
    Attribute VB_Creatable = False
    Attribute VB_PredeclaredId = True
    Attribute VB_Exposed = False
    Option Explicit
    cwOCX.cls
    Code:
    Option Explicit
    
    Public Event OCXEvent(pEventInfo As EventInfo)
    Private Declare Function SetParent Lib "user32" (ByVal hWndChild As Long, ByVal hWndNewParent As Long) As Long
    
    Private WithEvents but_SelfDestruct As CommandButton
    Private WithEvents HostedControl As VBControlExtender
    Private WithEvents Form As Form
    Private WithEvents W As cWidgetBase
    
    
    Public Property Get Widget() As cWidgetBase: Set Widget = W: End Property
    Public Property Get Widgets() As cWidgets: Set Widgets = W.Widgets: End Property
    
    Private Sub Class_Initialize(): Set W = Cairo.WidgetBase: End Sub
    Private Sub Class_Terminate(): Destroy: End Sub
    Private Sub but_SelfDestruct_Click(): Destroy: End Sub
    
    Sub Destroy()
        If Not Form Is Nothing Then
            Set but_SelfDestruct = Nothing
            SetParent Form.hWnd, 0
            Unload Form
            Set Form = Nothing
        End If
    End Sub
    
    Private Sub HostedControl_ObjectEvent(Info As EventInfo)
        RaiseEvent OCXEvent(Info)
    End Sub
    
    Private Sub W_AddedToHierarchy()
        Set Form = New fOCX
        Set but_SelfDestruct = Form.but_SelfDestruct
        SetParent Form.hWnd, hParentHWND
        
        Licenses.Add "MSComctlLib.TreeCtrl"
        Set HostedControl = Form.Controls.Add("MSComctlLib.TreeCtrl", "myctl", Form)
        Dim I As Long
        For I = 1 To 10
            HostedControl.object.nodes.Add Key:="Test" & Str(I), Text:="Test" & Str(I)
            HostedControl.object.nodes.Add Relative:="Test" & Str(I), Relationship:=4, Text:="TestChild" & Str(I)
        Next I
        
    End Sub
    
    Private Sub W_Hide()
        If Not Form Is Nothing Then Form.Hide
    End Sub
    
    Private Sub W_Show()
        If Not Form Is Nothing Then Form.Show
    End Sub
    
    Private Sub W_Paint(CC As cCairoContext, ByVal xAbs As Single, ByVal yAbs As Single, ByVal dx_Aligned As Single, ByVal dy_Aligned As Single, UserObj As Object)
        
        If Not Form Is Nothing Then
            Form.Show
            Form.Move xAbs, yAbs, W.Width * Screen.TwipsPerPixelX, W.Height * Screen.TwipsPerPixelY
            Static vFirstResizeDone As Boolean
            If vFirstResizeDone = False Then
                vFirstResizeDone = True
                W_Resize
            End If
            HostedControl.Visible = True
        End If
        
    End Sub
    
    Private Sub W_Resize()
        If Not Form Is Nothing Then
            Form.Move Form.Left, Form.Top, W.Width * Screen.TwipsPerPixelX, W.Height * Screen.TwipsPerPixelY
            HostedControl.Move 0, but_SelfDestruct.Height, Form.ScaleWidth, Form.ScaleHeight - but_SelfDestruct.Height
        End If
    End Sub
    
    Private Property Get hParentHWND() As Long
        Dim vP As cWidgetBase
        Set vP = W.Parent
        If vP.hWnd > 0 Then
            hParentHWND = vP.hWnd
            Exit Property
        End If
        While Not vP.Parent Is Nothing
            If vP.hWnd > 0 Then
                hParentHWND = vP.hWnd
                Exit Property
            End If
            Set vP = vP.Parent
        Wend
    End Property
    Attention: Before unloading the containing form you have to click "Self destruct" otherwise the app will crash. That is because the base widget has no "RemoveFromHierachy" event and we need to call SetParent and restore the original parent handle (0=Desktop) before unloading the form.

    Some other things regarding vbRichClient that came up during testing this (I only first used vbRichClient two hours ago, so maybe the following points are not valid, so feel free to correct me):
    - First of all: Great work! Looks very promising and I like the use of Cairo for Windows (my own UI framework just uses GDI+ and has a wrapper for that, but of course it uses OCX for the controls)
    - Resize should be called after AddedToHierachy
    - There should be a RemoveFromHierachy Event that is triggered before the widget is removed (also called during unloading of the parent form)

    I know that there still would be some issues - especially if a control searches it's environment to access another control and there are still some things. Another issue is of course that you cannot z-order a wrapped OCX control below a vbRichClient based widget because the widget is drawn to the form while the OCX control is an overlay. So it's far from perfect, but it still could provide support for some 3rd party controls that cannot be converted otherwise because we do not have the controls source code.

    I know that this would allow me to port my applications completely: I would convert my own controls (hopefully using an mostly automatic converter) to the new widget format while accessing the unconvertable 3rd party controls through wrapper widgets.

    It definetly isn't a solution for everybody but it would allow at least some degree of OCX use without the need for VB7 itself to support OCX controls.

    I am very interested to hear your opinion about this.

    Dominik
    Last edited by WhyWontIEdieAlready; Aug 24th, 2013 at 06:36 PM.

  9. #49
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by WhyWontIEdieAlready View Post
    @schmidt

    Sorry for posting so much, but I think I just found a simple solution to provide an OCX bridge widget based on your vbRichClient framework:

    It's pretty simple: We could develop a tool to automatically create a widget-wrapper for any given OCX Control.
    ...

    Thanks Dominik, for the proof of concept - and of course, as long as we produce 32bit-Binaries with VB7 - and the Vb6-Runtime is still available and working -
    we could use something like that in conjunction with the VB6-Form-engine (encapsulated in a VB6-COM-Dll), to perform the Form.Controls.Add-Call ...
    (which is the critical point in the whole exercise and does quite a lot of hidden and complex stuff under the hood with regards to the IOlexxx- UserControl-interfaces and siting).

    For those who want to "merge" vbRichClient5-Widgets and normal VB-Controls on the same Form in *VB6*, including correct Tab-Key support and stuff,
    there's the ucPanel.ctl approach - so one doesn't have to use a cWidgetForm as the only available GroundLayer for Widgets in VB6 - ucPanels can be used alternatively.

    Though for VB7-proper I'd like to have (if we do such a thing as your proposed OCX-bridging) a small Helper-Dll, written in MS-VC++ (with some help from ATL,
    which offers something similar as the VB6-Controls.Add-call with regards to easier siting-support for OCXes - so VC++ offers an easy way, to produce also a 64Bit-variant of such a helper).

    So, if that OCX-topic is dear to you (even when still unfamiliar with VC++), something like that would be a worthwhile addition (when encapsulated in a Dll,
    which in its first incarnation should play together and be tested with VB6 - just something which is able to "externalize" the VB6-Forms-Add-functionality -
    and is then usable independently from the VB6-runtime by the VB7-compiled-binaries in both, 32Bit and 64Bit mode).

    In case you never worked with VC++ - it's not all that "alien" - and "siting of an OCX per ATL" should be well-covered in online-articles and forums,
    where one can take a look how it's done.

    You will have a lot of time for that too, since I don't expect the compiler to produce something useful before at least 9-months or so are gone by.

    Regards,

    Olaf

  10. #50
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by jpbro View Post
    I've started contributing to the vbWidgets project on GitHub. While I use Git for my own projects, I'm the only developer which makes it easy to have my own "protocol" for submissions. I hope I've followed the proper protocol for your project, but please let me know if you would like things done differently.
    No, all fine - thanks - will respond (and merge your first additions) soon.

    Quote Originally Posted by jpbro View Post
    Regarding the controversy as to whether to support OCXs, it has become a polarizing issue.
    Do you see a path where the IDE can be developed to support a plugin extension that could offer some kind of OCX support (perhaps in a container widget that bubbles events up to the new form engine).
    Yes - something like the "fast shot from the hip" Dominik came up with as a first proof of concept is always doable (sidewards - and later on) -
    And "making an OCX visible somewhere on a Form" (the "basic siting", so to say) is not *that* difficult to achieve -
    neither over a small external VB6-Dll - nor over an (ATL-based) C++-siting-Dll-wrapper.

    The bigger problem is, to integrate those hWnd-based Controls with other Widgets on the same TopLevel-Form (layering-issues will happen because of Windowless vs hWNd-based) -
    and then we would need to support correct tabbing-integration - and finally (what you already hinted at) - a proper Event-integration into the WidgetForm-Event-Bubbling-mechanism.
    That's all solvable of course (in one way or another) - but "a distraction" nonetheless in the early stages of the project - because we already have a fully working "UserControl-Engine"
    (which is more powerful than the MS-one and should therefore be preferred).

    Quote Originally Posted by jpbro View Post
    This would allow a second group of interested parties to spend effort developing OCX support, while the rest of the team that doesn't really care for it can ignore those efforts and work on the rest of the IDE.
    Sure, I'm not hostile against such efforts - anything which broadens the user-base is a good thing in the end - and should be integrated when tests show, that it plays well with the existing engine...
    I'm just trying to steer a straight course to platform-independence, which currently seems not that important to many VB6-Devs - but it will become so in a few years- I'm deeply convinced of that.
    That's why I labeled the OCX-support (somewhat undeserved maybe) "a distraction" - (from the Widget-Engine)... you will not be able to "take OCXes with you", in case of a platform-switch.
    The Widget-Engine (along with more and more well-written additions to the free available Widget-stack) should be the preferred kind of GUI-approach.

    Quote Originally Posted by jpbro View Post
    This would also help to entice VB6 developers over who think they need OCX support, and introduce them to the new IDE and new features of framework. While they get comfortable with the new environment, over time they could migrate their apps completely off the OCXs and gain full cross platform, 64-bit, unicode, etc... functionality.
    As said, if there's a group of interested Users who come up with a nicely sidewards-bindable OCX-Bridging-approach - we should integrate it into VB7 (even if I'm not a fan of OCXes <g>).

    Regards,

    Olaf

  11. #51
    Addicted Member
    Join Date
    Mar 2009
    Posts
    244

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Schmidt View Post
    I'd try to mimick the old IDE (maybe just introduce some nicer Icons) as far as possible (the non-SDI-version I mean).
    Olaf
    i do hope the SDI version is also taken into account, as that's how I use the IDE, don't like the mdi. Also extensibillityis very important, the current vb6 ide has some nasty shortcomings,which are very noticable under windows 7 (using source safe 5).
    We use MZ-tools for extending the ide, and our own addins (no i don't suggest the ide should be compatible with those, far from it, it's pretty crap, a lot of our add-in code consists of working around the crappy extensibility, not on actually the functionss themselves.)

    One of the reasons why i would want my current vb6 projects to be able to just convert and continue in vb7 is due to some stupid limitations of the vb6 ide/project size. sadly there is some sort of limitation on the ammount of differently named variables in one project (yep, i'm hitting that limit, which results in 'out of memory' errors in the ide.. also one of the most annoying things of the ide/intellisense of vb6 is that it doesn't limit the name of a method/property/parameter/variable to the specified scope, but on the whole project, which is especuially annoying if you are using something like sourcesafe, for example take a property 'X' (uppercase X)on a class, but if you use an ocx or some default api declaration where a variable is called 'x' (lowercase x), the ide changes the name of the class property to 'x' or if you add the class after the api-declarating, it will change the parameter 'x' to 'X'... VERY ANNOYING, so i do hope something like that is fixed.
    the reason i want everything in one project is due to not wanting to have to worry about dll-hell, that way i know the specified project always uses the versions of the controls it needs to have, and i don't have to worry about my ocx-es/dll's don't have to be s 'backwardcompatible'. so i hope the new ide will fix the limitations/annoyances..
    Also the advantage of having 100% compatibility is you can immediatly start using new functionalities for new parts, and replace/upgrade older parts when needed...
    I also mentioned sorcesafe for a moment, good sourcecontrol integration is also ver needed in the new ide..

    ps. i still haven't had time to checkout the framework.

  12. #52
    PowerPoster
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    2,412

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Schmidt View Post
    No, all fine - thanks - will respond (and merge your first additions) soon.
    Great! No rush to merge of course, and criticism of my code is always welcome if it is not up to snuff. I just wanted to "fly the flag" a bit about contributing to the effort.

    Quote Originally Posted by Schmidt View Post
    Yes - something like the "fast shot from the hip" Dominik came up with as a first proof of concept is always doable (sidewards - and later on) -
    And "making an OCX visible somewhere on a Form" (the "basic siting", so to say) is not *that* difficult to achieve -
    neither over a small external VB6-Dll - nor over an (ATL-based) C++-siting-Dll-wrapper.
    The bigger problem is, to integrate those hWnd-based Controls with other Widgets on the same TopLevel-Form (layering-issues will happen because of Windowless vs hWNd-based)...
    Frankly, I'm not too concerned about the details "today" because I think that if it is technically feasible, and can be done in such a way that it is not a major distraction to the core project (that is to say that another group of programmers who otherwise wouldn't want to get involved, but are willing to work on OCX compatibility without taking too much effort away from the core programming group), then why not?

    Quote Originally Posted by Schmidt View Post
    Sure, I'm not hostile against such efforts - anything which broadens the user-base is a good thing in the end
    I agree.

    Quote Originally Posted by Schmidt View Post
    I'm just trying to steer a straight course to platform-independence, which currently seems not that important to many VB6-Devs - but it will become so in a few years- I'm deeply convinced of that.
    I 100% agree that platform independence is a primary goal. I only see OCX support as a temporary bridge.

    A personal anectode: I initially fought against legacy support when developing the latest version of our software, even though my boss thought that it was critical. I fought because it was going to be a lot of painful work to understand some ancient proprietary binary formats (circa 1993, for which there was no documentation), and to deal with non-normalized Access databases that didn't even store the data needed to be used with some of the new features of the software. At first I "won", but over time it was evident that many of our "old" customers needed to see something that they were familiar with in the new program to really understand the fundamental shifts in the approach that we were taking with the new version. So in that sense, I was wrong, and I eventually took the time to create a migration path for them. When new features were impossible to use (because the data didn't exist from the legacy software for example), then it at least gave the users an understanding of what they were gaining by starting from scratch with the new program. Because of this experience, I think that OCX support (or at least the ability for interested developers to easily integrate some kind of OCX support in "VB7") would be useful.

    Quote Originally Posted by Schmidt View Post
    The Widget-Engine (along with more and more well-written additions to the free available Widget-stack) should be the preferred kind of GUI-approach.
    I agree.

    Quote Originally Posted by Schmidt View Post
    As said, if there's a group of interested Users who come up with a nicely sidewards-bindable OCX-Bridging-approach - we should integrate it into VB7 (even if I'm not a fan of OCXes <g>).
    I agree, for reasons stated above. I think the only concern of the core IDE dev team regarding OCX support should be that it is relatively easy for an OCX-compatibility dev team to integrate their work into the main project (what I don't know is how this will be done - I would prefer an extension/plugin framework, as opposed to a different build of the IDE.)

  13. #53
    PowerPoster
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    2,412

    Re: VB Classic (A True VB 7.0)

    @SuperDre & Olaf

    Maybe a new thread should be started to discuss the complaints about the old IDE and what features we would all like in the new IDE?

  14. #54
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by jpbro View Post
    @SuperDre & Olaf

    Maybe a new thread should be started to discuss the complaints about the old IDE and what features we would all like in the new IDE?
    I'd find that not necessary at the moment - in my initial GIT-Repo-Opener-Step (just give me a few more weeks, to bundle something up),
    I will upload a wireframed and widgetbased-Version, which in its "Panel-Areas" tries to mimic the current VB6-MDI-version (most of the PanelAreas still empty,
    only filled with mockups or stubs). Also the Menu-Stripes and ToolBar-Stripes I will only provide with the first entries - and the modal-dialogues
    I will replace with a generic "Todo-MessageBox".

    From that Wireframe it should be easier then, to "spread the work-load" without causing team-efforts to overlap.

    I'd like it when we could use *this* Forum here for the rough overview, where the project currently is, reflecting the current
    state in a kind of "still open, ...already worked on by PersonX, ...already finished"-List where developers can "check themselves in"
    for a certain Todo-task, to fill the "still blank spots" in the wireframe-model - and make it clear for others, who's currently working on what -
    which are the Todo-Tasks which are still "open" - and what tasks are already done ...

    Maybe *that* should then go into a new, separate Todo-Thread, where the initial post is used to reflect the current state.

    Basically I'd like to treat the GUI in the same way as the initial requirement for *.bas and *.cls compatibility - let's discuss enhanced features
    (much) later - first let's try to come up with something which resembles the original as closely as possible - only if there are
    "cheap and obvious enhancements possible already in the first throw"- then of course let's apply them - but those topics will
    then come up along the way in the GIT-repo-Pull-Requests - and we could discuss implementation-details there then.

    Edit: Forgot to comment on the SDI-capabilities of the old VB6-IDE - and how to achieve that in the VB7-IDE...

    This feature would (if there's enough contributors who'd be willing to approach this) not that difficult to implement,
    since in the new Form-engine (which offers the hosting-areas for the new Widget-Framework) there's no difference between
    "Client-Panels" or "TopLevel-Forms" - both are of type cWidgetForm.

    So, Code (and Widgets) on a certain Panel (interacting with such a cWidgetForm-Base), which in the first throw will be implemented as Docking-Areas -
    can later on easily be hosted also in a TopLevel-cWidgetForm-instance (ToolWindows etc.), by just switching the instantiation-line of the cWidgetForm-variable -
    so SDI-mode will not be a real problem if that is wanted - but it can be achieved later on, without "wreaking havoc" in the original CodeBase - and so I'd like to
    delay this step until we came clear with the MDI-version initially (which I think is the mode, the VB6-IDE is currently used by most Devs).


    Olaf
    Last edited by Schmidt; Aug 26th, 2013 at 10:09 AM.

  15. #55
    Addicted Member
    Join Date
    Aug 2013
    Posts
    236

    Re: VB Classic (A True VB 7.0)

    Most of the discussion here has been above my head but I am really excited by this project.
    I'd be happy to help out if there was work within my capabilities available though.

  16. #56
    Addicted Member
    Join Date
    Mar 2009
    Posts
    244

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Schmidt View Post
    Edit: Forgot to comment on the SDI-capabilities of the old VB6-IDE - and how to achieve that in the VB7-IDE...

    This feature would (if there's enough contributors who'd be willing to approach this) not that difficult to implement,
    since in the new Form-engine (which offers the hosting-areas for the new Widget-Framework) there's no difference between
    "Client-Panels" or "TopLevel-Forms" - both are of type cWidgetForm.

    So, Code (and Widgets) on a certain Panel (interacting with such a cWidgetForm-Base), which in the first throw will be implemented as Docking-Areas -
    can later on easily be hosted also in a TopLevel-cWidgetForm-instance (ToolWindows etc.), by just switching the instantiation-line of the cWidgetForm-variable -
    so SDI-mode will not be a real problem if that is wanted - but it can be achieved later on, without "wreaking havoc" in the original CodeBase - and so I'd like to
    delay this step until we came clear with the MDI-version initially (which I think is the mode, the VB6-IDE is currently used by most Devs).
    But implementing it from the start makes sure you won't have any problems later on.. Also with modern MDI you can just drag a window out of the MDI-parent (at least in VS.NET) so in some way you do have SDI..
    But personally I'm not that fond on MDI, the only thing I like about MDI is the fact if you maximize a child-window it will position itself within the MDI-clientarea, but we 'fixed' that for SDI in our add-in so you can 'one of the options of our addin we created is that a code window will position itself under the VB6-main-toolbar and is limited to the project-window (or whatever you want).. It works a bit like the old Delphi IDE (and it's best addon G-Expert).

    But are 'you' gonna use the vb6 IDE as the example IDE or are 'you' also looking at other IDE's?

  17. #57
    Banned
    Join Date
    Jan 2014
    Posts
    50

    Re: VB Classic (A True VB 7.0)

    Please read this: http://www.codeproject.com/Articles/...rful-than-ever


    Quote Originally Posted by Jacob Roman View Post
    Introduction:
    Its been many years since MS dropped support for VB6, yet people continue to use it to this very day. Many users have switched over to VB.Net due to how powerful it is, and the fact that its truly object oriented. But some find the runtime too large, and their apps are too dependent on the .NET Framework. The on going battle between VB6 lovers and VB.Net nuts must come to an end. Its time we developers unite to create the ultimate VB language that's fast and easy to use. A language that is extremely RAD (Rapid Application Development). Its time for VB Classic.

    Why VB Classic?
    VB Classic if done right will be the solution to every VB developers problems. People as well as businesses continue to use VB6 for a reason. Either its too expensive and time consuming to switch to VB.Net and port all that code, or some people find VB6 easier to code for than VB.Net. Some people also find VB.Net lingering away from the BASIC syntax that we all once recognized. But people use VB.Net for a reason too. Its powerful, the latest technology, and actually object oriented. Some find VB.Net easier to code for than VB6. But what draws you in to stick with your favorite VB language regardless of version you use? What do you not like about it? If we all iron out the flaws of VB, we can create an improved VB language, and make it easy to migrate to from both sides of the fence without overwhelming you with a completely new syntax. A lot of people find both languages have very slow functions they would like to see execute faster for example. VB Classic will have very familiar commands execute as fast as humanly as possible so you will have no worries of slowdown in time sensitive projects such as games!

    Can I be a part of the Team?
    I will need a team of people to help me put this together. You can PM me or say you want in here in this thread, but you must be serious about joining. Before we even begin to jump into syntax, I would like help in putting together the IDE. Once we have an IDE to work with, then we can discuss syntax. The reason is because if we talk about syntax, we can go on and on until theres about 20 pages of a super thread going, but.... no IDE was made. I don't want to make the same mistake that happened with LightFusion, and its a must that progress must be made. The IDE will be designed in C++ starting with the basic window, the menu items, and the code window within the window. As we progress, then we can add special things such as a toolbox and such. The IDE is a must before a syntax can be formed.

    IMO I think eyeRmonkey did a better job in creating an intro for developing a new programming language
    http://www.vbforums.com/showthread.p...ht=lightfusion

  18. #58

  19. #59
    Junior Member
    Join Date
    Aug 2011
    Posts
    28

    Re: VB Classic (A True VB 7.0)

    Here has vb.net's compiler source code:
    in the sub dir DotNetReferenceSource.zip\Source\vb of the below package
    http://referencesource-beta.microsoft.com/download.html

  20. #60
    Banned
    Join Date
    Jan 2014
    Posts
    50

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by mjohnlq View Post
    Here has vb.net's compiler source code:
    in the sub dir DotNetReferenceSource.zip\Source\vb of the below package
    http://referencesource-beta.microsoft.com/download.html
    is this legal ? hmmmmm VB .NET compiler source code

    VB6 compiler source codes ?
    Last edited by Fatina; Feb 24th, 2014 at 10:32 PM.

  21. #61
    Junior Member
    Join Date
    Aug 2011
    Posts
    28

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Fatina View Post
    is this legal ? hmmmmm VB .NET compiler source code

    VB6 compiler source codes ?
    vb.net compiler source is open source by microsoft, so i think it is legal.
    but vb6 compiler source code is not open sourced by microsoft.

  22. #62
    Banned
    Join Date
    Jan 2014
    Posts
    50

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by mjohnlq View Post
    vb.net compiler source is open source by microsoft, so i think it is legal.
    but vb6 compiler source code is not open sourced by microsoft.
    Visual Basic 6.0 it is not open source because is too important, true ! thanks for the link, I did not know that VB .NET is open source

  23. #63
    Junior Member
    Join Date
    Aug 2011
    Posts
    28

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Fatina View Post
    Visual Basic 6.0 it is not open source because is too important, true ! thanks for the link, I did not know that VB .NET is open source
    you are welcome.
    I just know it today too. from this link:
    http://visualstudio.uservoice.com/fo...t-framework-so

  24. #64
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Fatina View Post
    is this legal ? hmmmmm VB .NET compiler source code
    VB.NET-compiler source (non-MS) is out there for years under Mono, written and maintained
    by Rolf Bjarne Kvinge...

    In either case (although I'd think that the Mono-license is a bit more liberal than the MS-
    conditions which come with their source), I'd suggest not to look at it (in depth), and
    definitely not to copy portions from it, just to be on the safe side.

    Olaf

  25. #65
    Banned
    Join Date
    Jan 2014
    Posts
    50

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Schmidt View Post

    In either case (although I'd think that the Mono-license is a bit more liberal than the MS-
    conditions which come with their source), I'd suggest not to look at it (in depth), and
    definitely not to copy portions from it, just to be on the safe side.

    Olaf
    true

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

    Re: VB Classic (A True VB 7.0)

    Just to let you know my position, I would definitely contribute toward a kickstarter-like project for a more up-to-date VB6 IDE that was able to be language-aware with language specific functionality being enabled/disabled via configuration/plugins. Personally, I'd like a new IDE to be as much like the old VB6 IDE as possible. That is what made me productive and I'd like it to continue. Jabaco came up with a pretty good first stab at a VB6 IDE look/act-alike but that project is dead in the water. I think a new non Microsoft IDE is an achievable objective that would be just the first step to reinvigorating VB6 and jumping off point for VB7.

    For VB7 to succeed it simply needs to do one thing - compile and run our programs.

    Any new functionality needs to be in addition to supporting the old. Once again, I would be willing to contribute to a kickstarter-like project that would create a VB7 compiler on windows. Initially, if it was only for windows I would be happy but if later compilers could create code for Android that would complete the picture. Each compiled could be a separate kickstarter project.

    The only VB7 enhancement that I see that would drive me to wanting it 'desperately' is better handling of transparencies to allow transparent/semi-opaque images behind controls/backgrounds &c. This would allow shaped applications like these:


  27. #67
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by yereverluvinuncleber View Post
    The only VB7 enhancement that I see that would drive me to wanting it 'desperately' is better handling of transparencies to allow transparent/semi-opaque images behind controls/backgrounds &c. This would allow shaped applications like these:
    You can already achieve everything I see on your screenshot with the vbRichClient-framework (a free set of 3 Dlls for VBClassic).
    With ease, since it supports not only vector-based, antialiased Drawing (as well as all kind of alpha-channel-Bitmaps and Icons - gaussian blurring etc.), but also a new Form- and UserControl-engine (in the context of the Framework I call those new UCs "Widgets" - they can be developed quite similar to normal VB-Usercontrols, but in addition come with an Alpha-Transparency- as well as a .Moveable property, MouseWheel-Events, MouseIn/Out etc... the Framework is Unicode-capable throughout).

    Just install the "BaseDlls" first:
    http://vbrichclient.com/#/en/Downloads.htm
    (and read what's stated below the Download-link with regards to registry-entries).

    And then check out the well-commented Tutorials/Demos, in the order they are listed on this page:
    http://vbrichclient.com/#/en/Demos/GUI/
    - CairoDrawing
    - FormEngine
    - WidgetEngine

    Each of the above contains a list of Folders, ordered from "easy" to "advanced" -
    each Folder is self-contained (not dependend on the Source-files in other Folders).

    Olaf

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

    Re: VB Classic (A True VB 7.0)

    I thank you for that information and I will certainly have a look at those references you have provided.

    I have already created these using javascript and XML as genuine desktop widgets using the Yahoo widget engine, the IDE was Photoshop for the graphics and Context Editor for the code using a conversion script to convert the PS layers to an XML description.

    I might have used VB6 if the future for VB6 had been perceived, at the time, as being more secure. However, even the Yahoo widget engine has been abandoned and so I am now looking for a new development platform. Considering Xwidget engine (Windows/Android) and/or QT (most of them)

    This is another that I have created as a widget so you can see the sort of thing I now knock up:


    Regardless of whether I could fulfil my current needs with VB6 I'd still support an open source multi-language VB6-like IDE and I'd contribute toward a VB7 in one way or another.

  29. #69
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB Classic (A True VB 7.0)

    Nice graphics (and graphics skills)...

    As for good-looking, *.png-based and antialiased "AnalogueClock-KnockUps"
    (though still kept simple, without the Date-Visualizings and Moon-phases) -
    this vbRichClient-based Widget-Demo is perhaps interesting to you as well:

    http://www.vbforums.com/showthread.p...-ClockHands%29

    Aside from the rich graphics-capabilities which offer anything you're perhaps wont also from the other engines (including SVG as well) -
    the framework also integrates a physics-engine (a chipmunk-binding behind easier to use COM-classes), so that
    you could design physically correct behaving mechanics too... (a motor, all kinds of "joints" and springs ... it's all there).

    As for VB7 (and a new IDE which is based on the new Widget-Engine) - currently have not that much time as I'd like -
    though the project is still on my todo-list... will post here, when I have something to show and make the next move with that...

    Olaf

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

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Schmidt View Post
    Nice graphics (and graphics skills)...
    Complement appreciated... Having just read the description on your site and seeing what you have already done and what you intend to do, I am more than impressed by your programming skills. My graphic skills certainly exceed my programming skills (I am really no more than a scripter with initiative).

    Time is what none of us have but if it encourages you, I am really impressed that someone is delivering the components that you are producing. These were needed a long while ago...

    My apologies for showing more of my stuff but as you seem to like it...

    Last edited by yereverluvinuncleber; Feb 25th, 2014 at 06:05 PM. Reason: added image

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

    Re: VB Classic (A True VB 7.0)

    Looking at your rather attractive clock widgets - I'm going to have to reconsider VB for widget-making.

    FYI - my javascript widgets are here: http://lightquick.co.uk/steampunk-wi...tml?Itemid=264

    Don't have high expectations of my code but the widgets do work mostly. The widgets are zipped in a .WIDGET file, there is a converter on the download page that makes it easier to unzip the widgets. Feel free to convert if you want.

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

    Re: VB Classic (A True VB 7.0)

    Chaps. One thing that might help with any possibility that MS might break the platform and remove something like OCX capability - ReactOS. I have some high hopes for ReactOS, an open source re-engineered version of widnows (sic) which is similar in concept to what you are thinking of doing with a new VB7. ReactOS is based upon the functionality of NT 5.2 and is already bootable/runnable in alpha and will be going to beta probably on the next release.

    If it is successful, ie. it goes beta then live and it appears usable, then it should provide a platform for the future for all VB6/VB7 apps in that it will not break backward compatibility just for the sake of Microsoft doing so.

    I think that any developers of a future VB7 should have a stake in what the ReactOS boys are doing as I reckon it could be a partnership made, well, not quite in heaven, but close.

    https://www.reactos.org/



    Don't expect it to install/run VB6 yet - it isn't quite there yet. It runs lots of app.s but the memory management is still flaky, the explorer and task manager are being re-engineered now and a lot of what is there is in place because they needed something to just 'work'.
    Last edited by yereverluvinuncleber; Feb 26th, 2014 at 05:53 AM. Reason: added more about ReactOS

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

    Re: VB Classic (A True VB 7.0)

    Interesting thought that when you distribute your VB6 app you could bundle an o/s with it too, almost like a runtime library...

  34. #74
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB Classic (A True VB 7.0)

    I'm following ReactOS for a long time now, it started out well, but progress is really slow in the meantime
    (they're still not yet at the point of true "Windows-Driver-compatibility" - which could give a boost when
    that'd be ready).

    In UserLand (atop the kernel- and driver-layer) they are using SourceCode from the Wine-Project.


    Quote Originally Posted by yereverluvinuncleber View Post
    Interesting thought that when you distribute your VB6 app you could bundle an o/s with it too, almost like a runtime library...
    Have already validated this approach about 1.5 years ago (with a tinycore-linux,
    which comes in a ~12MB-package, including a modern kernel and a Desktop-GUI).
    http://www.tinycorelinux.net/

    Linux+Wine is still the (much) more stable approach, compared with ReactOS.

    After installing the Wine-package from the TinyCore-Repository, followed by an
    install of the VB6-runtime-Files - VB6-apps were able to work on that system.

    Size as a VMWare-package/disk (including the quite large Wine-Layer-libs) was about 45MB
    or so (7z-compressed about 30MB) - so, yeah - a complete, modern OS, able to run VB6-apps
    on top, was thus smaller than e.g. an update-package for the 4.xxx .NET-runtimes ...

    But resorting to that kind of thing (shipping VB6-Desktop-Apps as a VM) will not
    be required IMO for a long time to come - Win9 will support VB6 and COM definitely
    further - there's just too many Apps in all the Offices around the globe (even a whole
    lot of .NET-based ones) which cannot function without Win32 and/or COM.

    Olaf

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

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Schmidt View Post
    Size as a VMWare-package/disk (including the quite large Wine-Layer-libs) was about 45MB
    or so (7z-compressed about 30MB) - so, yeah - a complete, modern OS, able to run VB6-apps
    on top, was thus smaller than e.g. an update-package for the 4.xxx .NET-runtimes ...
    That is a great approach and I'll consider that for the future too! I'd also like to get my yahoo widgets running under wine but the engine does not work due to some missing graphic functionality.

    I have seen ReactOS firm up a little with the last release but you are quite right it seems to make slow progress - it is a momentous task to attempt. Hoping that when it turns to a beta release the momentum will start to be generated. I feel that ReactOS is a hard project to contribute towards due to the nature of the developers, they don't always seem a communicative bunch though this has also improved recently.

  36. #76
    Hyperactive Member
    Join Date
    Jul 2002
    Posts
    481

    Re: VB Classic (A True VB 7.0)

    Hello Everyone,

    As most of you know I have been driving hard to promote the vote to MS to bring back VB6. I actually had a conversation with someone at MS a week ago, and although he is lead guy of another team not associated with vb, he kept stating that bringing the product back is highly unlikely because most modern development needs more... So funny. After the phone conversation I asked him to give me a list of things that would help my app if I re-wrote it .net. I have yet to hear from him. I think I would be stupid to actually move to .net, again trusting a company that deserves no trust.

    I have also talked via forum to the people at xerocoder.com and suggested they create a convertor for vb6 code to import to their platform. They feel that they could create a convertor that can convert up to 95% of vb6 code. They use a macro system that allows you to create language keywords to convert what they have to vb6 syntax, pretty neat. I hope they decide to go for it.

    Schmidt is a true genius and I wish there was a way to give him the funds he needs to get the project done, although I REALLY do agree with yereverluvinuncleber that a vb6 replacement must be able to compile a vb6 app as they run today. The way I see it that, and that alone will have vb6 devs all over the world run to its adoption. I know that may hinder the fact that it will be cross platform and win32 dependent, but those things can be much easily re-factored if a compile from current vb6 code can be achieved, all extra effort can then be focused on cross platform and removal of win32 dependencies.

    I am really crossing my fingers that one of these four things happens this year
    / MS brings back vb6
    / xerocoder implements a true vb6 import
    / Schmidt finds time and money to complete his project
    / or anything comes to market as a true vb6 replacement.

    That's my 2 dollars and 50 cents!
    Good Day!

  37. #77
    Banned
    Join Date
    Jan 2014
    Posts
    50

    Re: VB Classic (A True VB 7.0)

    Hello Everyone,

    I am disgusted by the banning of Megan Winter's account on social.msdn.microsoft.com. She came with valid points for Visual Basic 6.0, too valid! And what the administrator/power user does on a MICROSOFT site?! He (the power user) erased all 60-70 valid comments (on "Bring back Visual Basic 6.0 ! We all need it." issue) and banned the acount due to his inability to cope with the conversation! This guy is a disgrace for Microsoft! The admin that banned a perfect valid user like Megan Winter should not have access to that site ! The name of this power user is Cor Ligthert. Please comment there: http://social.msdn.microsoft.com/For...orum=vbgeneral

    Folks, what happened to Megan Winter is NOT ok !


    PS: yes, but it will not be the same. I also agree that a vb6 replacement must be able to compile a vb6 app as they run today (and this is the most important thing!). These points are important: http://vb6awards.blogspot.ro/2014/02...-basic-60.html

  38. #78
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB Classic (A True VB 7.0)

    Cor Ligthert "terrorized" (toghether with a few cronies) the VBClassic mpvbgd-usenet-group for years.

    And he's not at all good at the kind of "marketeering" he did then and there (although it's
    much better than trying to talk with him about programming-topics, been there - done that).

    Cor easily raises (involuntarily for the most part) ignorance to an art-form (to be fair, that's
    partly because of his bad english skills)
    So, in short: you can as well have a nice conversation with a brick-wall - at least the responses
    you'll get then, will be consistent and non-contradictory.

    Just forget about it.


    Olaf

  39. #79
    Banned
    Join Date
    Jan 2014
    Posts
    50

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Schmidt View Post
    Cor Ligthert "terrorized" (toghether with a few cronies) the VBClassic mpvbgd-usenet-group for years.

    And he's not at all good at the kind of "marketeering" he did then and there (although it's
    much better than trying to talk with him about programming-topics, been there - done that).

    Cor easily raises (involuntarily for the most part) ignorance to an art-form (to be fair, that's
    partly because of his bad english skills)
    So, in short: you can as well have a nice conversation with a brick-wall - at least the responses
    you'll get then, will be consistent and non-contradictory.

    Just forget about it.


    Olaf
    So true Olaf, you're right!

  40. #80
    Addicted Member
    Join Date
    Mar 2007
    Location
    India
    Posts
    227

    Re: VB Classic (A True VB 7.0)

    As the project is still on drawing board I would suggest to have look as a similar compiler B++. It is on sourceforge web site.

    It seems to be abounded but it can be a starting point for this new project. It is basically an emitter which will generate C++ code in back end and compile it with either MingW or BorlandC++ (free compiler).

    While we are at it.

    I would like to know if it would possible to use LLVM for targeting multiple OSs?

    HTH

    Yogi Yang

Page 2 of 4 FirstFirst 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