vb4linux-dev Mailing List for Visual Basic for Linux (Page 3)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

any idea how we could reuse the existing WinAPI for VB?

On Mon, 20 Nov 2000, Abhijit Paithankar wrote:

> The debugger should be in VB.
> This also means, we should be able to reverse interpret the C code.
> 
> another way would be to parse the VB code itself and make sure there are (if
> possible) no erors (syntax or logical)in the code even before putting it
> thro vb2c.
We should beable to add debugging functions on the C side with no problem,
again like Python and Tcl have. (always look to the past to see the
future)

> 
> >
> > As this project is meant to be a near-exact port of Visual Basic
> > (besides the
> > binary result and OS), the debugger should be VB.....
> >
> > > I think it best to keep this part of the code as hi-level as
> > > possible.  And again it does not matter if it is not compiled or
> > > compilable for awhile, without a good solid core (vb2c) it's useless
> > > anyway.  The debugger is upfor debate on if it should be in C or
> > > VB.  Though in the Tcl/Tk and Python world their debuggers are mixed.
> 
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev
> 
> 

On Sun, 19 Nov 2000, Luke-Jr wrote:

> Scott Beasley wrote:
> 
> > Lets go over some issues and options we have in writing vb2c.
> >
> > 1 - The main translator does not have to be in C. (I vote C tho :-)
> >     We could write the translator in something like Tcl or Python.  This
> >     would be for VB->C code generation only.  The support libraries would
> >     still be in C, and would be brought in during link time.  Doing this
> >     would simplify much of the parsing of the vb files, and would be
> >     relatively fast.
> 
> Tcl seems to be X11-only... The VB2C shouldn't require X11 as it isn't a
> GUI app...
Tcl is not Tk in this case (Tcl is the scripting language and Tk is the
windowing Tool Kit)  Tcl, Tk and Python are quite portable though, as
portable as perl even.

> 
> >
> >
> > 2 - vb2c will have to be a multi-pass compiler or use very complicated
> >     Look ahead logic. (I vote multi-pass)
> >     We will need at least 3 passes to generate the code or a foo-bar FSM
> >     (Finite state machine).  You could/can generate most of the form info
> >     (Window info) on the first pass, as most of that is close to a one to
> >     one relation (i.e. Windows created -> Windows create code in C)  But
> >     branching, looping and such needs more info before you can generate
> >     the target code.  If & Select blocks also can change the flow of code,
> >     so they need extra attention (more on these later also).
> 
> I know this may sound stupid, but why must it be multi-pass? Maybe if it's not
> Option Explicit then there might be a reason to need that, but even still for
> non-OE programs there could be one "default" type which could be a wildcard...
Not stupid :-)  This is just part of writing a compiler or language
translator.  For a translator you could do it single pass, but you could
generate better code (and less) with a multi-pass system and also do some 
optimization on the last pass.

> 
> >
> >
> > 3 - A Type marshalling engine will be needed.
> >     To keep things simple, we should have functions written to help out
> >     with type converting (obvious) and things like If and Selects.  C has a
> >     much more limited type comparison set.  Such as switch/case. In C this
> >     is integer based (which is fine) but in VB select is not.  We will
> >     have to a set of functions or an engine to handle this.
> 
> Well, I'd say making the "Select Case abc" become "select(MakeSelectInt(abc))"
> and have MakeSelectInt do an interger "encode" on the value and have maybe the
> first byte be representing the original type or something like that...
> 
> >
> >
> > 4 - Others?
> >
> > just a few things to think about.
> >
> > scott
> >
> > _______________________________________________
> > VB4Linux-Dev mailing list
> > VB4...@li...
> > http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev
> 

Just an idea:

There should be two states a program can be in, Debug and Release (just
like VC++). While the program is in Debug, it would compile to bytecode
and an interpreter runs this code. This should make debugging facilities
a bit easier to program. When the programmer wants to Release his/her
program to the public, he/she selects 'Make <program name>' from a menu
(as in VB) and the program is natively compiled and debug info in the
source code is ignored (VB ignores Debug.Print statements when it is
Make-ing the program). There is also another Basic project (KBasic)
being developed at the moment, perhaps the bytecode should be compatible
with that?

it is always better to break the project into smaller modules. Sure, it does
need you to think about interoperatibility; which can be solved thro'
meticulous planning, but then the advantage is that the bugs in the program
are localized....plus things can be worked upon/upgraded independently
without affecting other things and introducing newer bugs in the software.

I feel one big program is more trouble than few small programs.
I recommend modular approach.
ab

> -----Original Message-----
> From: vb4...@li...
> [mailto:vb4...@li...]On Behalf Of Luke-Jr
> Sent: Monday, November 20, 2000 1:35 AM
> To: vb4...@li...
> Subject: [VB4Linux-Dev] Erm... I hate subjects... ;-P
>
>
> Anyway, does anyone have a good reason why we shouldn't do everything
> in VB4Linux (besides VB2C... for now at least)? Because if there's no
> objections, I'd like to get started on the GUI and since we haven't
> really decided on a definate GUI interface (GTK+, GNOME, KDE, etc...),
> making it in VB would leave that open to modification until we get to
> that part of VB2C...
>
> Is there anyone here who has access to a working Visual Basic for
> Windows (VB5 with Wine works I think) who also wants to work on the
> GUI? Until someone else wishes to do some development with the GUI, I'm
> going to keep it to local files... So just email me or the list if you
> want to help develop the GUI... Also, I won't start for at least an hour
> so that ppl have plenty of time to specify reasons why the GUI shouldn't
> be done in VB...
>
> Thx!
>

The debugger should be in VB.
This also means, we should be able to reverse interpret the C code.

another way would be to parse the VB code itself and make sure there are (if
possible) no erors (syntax or logical)in the code even before putting it
thro vb2c.

>
> As this project is meant to be a near-exact port of Visual Basic
> (besides the
> binary result and OS), the debugger should be VB.....
>
> > I think it best to keep this part of the code as hi-level as
> > possible.  And again it does not matter if it is not compiled or
> > compilable for awhile, without a good solid core (vb2c) it's useless
> > anyway.  The debugger is upfor debate on if it should be in C or
> > VB.  Though in the Tcl/Tk and Python world their debuggers are mixed.

Not at first, but I hope with time that we'll be able to work in optimization
generators for the conversion... After all, VB for Windows does some internal
program conversion and optimization itself (no, VB5+ don't go straight to
binary, they convert it to some other ((maybe unknown)) language and optimizes
it... How else could there be "Optimize for Size" and "Optimize for Speed"?)...

Abhijit Paithankar wrote:

> > > For the GUI, I think you should program directly in C on the
> > Linux box. I am
> > > really doubtful of how powerful vb2c is at present....would it
> > be able to
> > > interpret all those toolbars, and "File Open" dialog boxes and all that?
> >
> > Well, nobody said that the GUI had to be compiled until the VB2C
> > part of the
> > project was done anyway... Besides, a complicated test program
> > would probably be a necessity when working on the VB2C...
>
> I see your point..
> but then you shall have to wait for a while before the vb2c is strong enough
> for it.
>
> again, the programs that have been compiled with vb2c might not be as
> optimized/fast as their C counterparts
>
> > > > > Pls check if Wine can emulate the OCX controls...and how do
> > we integrate
> > > > > them in the code that is to be converted to C...I am still not
> > > > sure about
> > > > > this stuff...
> > > >
> > > > Wine can emulate OCX controls... There's 2 possibilities for
> > > > including Windows
> > > > files:
> > > >     1. Link a modified version of Wine in with the program
> > and emulate the
> > > > OCXes only (if possible)
> > > >     2. Pre-emulate the OCX controls into C code and link a
> > > > "ported" OCX into
> > > > the program...
> > >
> > > Some team members could do some R&D on this topic. It would be of great
> > > help.
> >
> > R&D??
>
> Research & Development
> finding, trying and testing
>
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev

Scott Beasley wrote:

> Lets go over some issues and options we have in writing vb2c.
>
> 1 - The main translator does not have to be in C. (I vote C tho :-)
>     We could write the translator in something like Tcl or Python.  This
>     would be for VB->C code generation only.  The support libraries would
>     still be in C, and would be brought in during link time.  Doing this
>     would simplify much of the parsing of the vb files, and would be
>     relatively fast.

Tcl seems to be X11-only... The VB2C shouldn't require X11 as it isn't a
GUI app...

>
>
> 2 - vb2c will have to be a multi-pass compiler or use very complicated
>     Look ahead logic. (I vote multi-pass)
>     We will need at least 3 passes to generate the code or a foo-bar FSM
>     (Finite state machine).  You could/can generate most of the form info
>     (Window info) on the first pass, as most of that is close to a one to
>     one relation (i.e. Windows created -> Windows create code in C)  But
>     branching, looping and such needs more info before you can generate
>     the target code.  If & Select blocks also can change the flow of code,
>     so they need extra attention (more on these later also).

I know this may sound stupid, but why must it be multi-pass? Maybe if it's not
Option Explicit then there might be a reason to need that, but even still for
non-OE programs there could be one "default" type which could be a wildcard...

>
>
> 3 - A Type marshalling engine will be needed.
>     To keep things simple, we should have functions written to help out
>     with type converting (obvious) and things like If and Selects.  C has a
>     much more limited type comparison set.  Such as switch/case. In C this
>     is integer based (which is fine) but in VB select is not.  We will
>     have to a set of functions or an engine to handle this.

Well, I'd say making the "Select Case abc" become "select(MakeSelectInt(abc))"
and have MakeSelectInt do an interger "encode" on the value and have maybe the
first byte be representing the original type or something like that...

>
>
> 4 - Others?
>
> just a few things to think about.
>
> scott
>
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev

> > For the GUI, I think you should program directly in C on the
> Linux box. I am
> > really doubtful of how powerful vb2c is at present....would it
> be able to
> > interpret all those toolbars, and "File Open" dialog boxes and all that?
>
> Well, nobody said that the GUI had to be compiled until the VB2C
> part of the
> project was done anyway... Besides, a complicated test program
> would probably be a necessity when working on the VB2C...

I see your point..
but then you shall have to wait for a while before the vb2c is strong enough
for it.

again, the programs that have been compiled with vb2c might not be as
optimized/fast as their C counterparts

> > > > Pls check if Wine can emulate the OCX controls...and how do
> we integrate
> > > > them in the code that is to be converted to C...I am still not
> > > sure about
> > > > this stuff...
> > >
> > > Wine can emulate OCX controls... There's 2 possibilities for
> > > including Windows
> > > files:
> > >     1. Link a modified version of Wine in with the program
> and emulate the
> > > OCXes only (if possible)
> > >     2. Pre-emulate the OCX controls into C code and link a
> > > "ported" OCX into
> > > the program...
> >
> > Some team members could do some R&D on this topic. It would be of great
> > help.
>
> R&D??

Research & Development
finding, trying and testing

As this project is meant to be a near-exact port of Visual Basic (besides the
binary result and OS), the debugger should be VB.....

Scott Beasley wrote:

> On Sun, 19 Nov 2000, Luke-Jr wrote:
>
> > Abhijit Paithankar wrote:
> >
> > > pls see message below:
> > >
> > > > Erm... Fix your clock please? It's not the 20th and if you're in
> > > > a different
> > > > timezone, shouldn't it put the -0500 or something in the Date
> > > > header...
> > >
> > > Done sir! :)
> > >
> > > > > > >I think instead of giving 2 options, we could have just a VB2C
> > > > > > >interpreter.
> > > > > > Anyone looked at this: http://www.naken.cc/vb2c/
> > > > >
> > > > > It looks OK, but we shall have to request him for the source
> > > > code...atleast
> > > > > the basic stuff is already present....
> > > >
> > > > Yup...
> > > >
> > > > > Since a lot of work is to be done on the GUI/Editor, like being able to
> > > > > create a project and work within the project, the toolbars are to be
> > > > > emulated, and a lot of other stuff needs to be figured out, the
> > > > GUI/Editor
> > > > > can be developed independently and then the projectfile shall
> > > > be passed on
> > > > > to the VB2C compiler....actually, you could download the vb2c
> > > > interpreter at
> > > > > the URL above, and start off on that.
> > > >
> > > > Hmm... In that case, I could start on the GUI today... I'm MUCH better at
> > > > VB than C...
> > > > (I'll just have to remember not to use the WinAPI as I doubt VB2C
> > > > will make up
> > > > for that for a while...)
> > >
> > > yes...the earlier the better.
> > > also, we could use the latest version of GTK+...just make sure all of use
> > > the same versions of any libraries/software we use.
> > >
> > > For the GUI, I think you should program directly in C on the Linux box. I am
> > > really doubtful of how powerful vb2c is at present....would it be able to
> > > interpret all those toolbars, and "File Open" dialog boxes and all that?
> >
> > Well, nobody said that the GUI had to be compiled until the VB2C part of the
> > project was done anyway... Besides, a complicated test program would probably
> > be a necessity when working on the VB2C...
> >
> I think it best to keep this part of the code as hi-level as
> possible.  And again it does not matter if it is not compiled or
> compilable for awhile, without a good solid core (vb2c) it's useless
> anyway.  The debugger is upfor debate on if it should be in C or
> VB.  Though in the Tcl/Tk and Python world their debuggers are mixed.
>
> scott
>
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev

Lets go over some issues and options we have in writing vb2c.

1 - The main translator does not have to be in C. (I vote C tho :-)
    We could write the translator in something like Tcl or Python.  This
    would be for VB->C code generation only.  The support libraries would
    still be in C, and would be brought in during link time.  Doing this
    would simplify much of the parsing of the vb files, and would be
    relatively fast.

2 - vb2c will have to be a multi-pass compiler or use very complicated
    Look ahead logic. (I vote multi-pass)
    We will need at least 3 passes to generate the code or a foo-bar FSM
    (Finite state machine).  You could/can generate most of the form info
    (Window info) on the first pass, as most of that is close to a one to
    one relation (i.e. Windows created -> Windows create code in C)  But
    branching, looping and such needs more info before you can generate
    the target code.  If & Select blocks also can change the flow of code,
    so they need extra attention (more on these later also).

3 - A Type marshalling engine will be needed.
    To keep things simple, we should have functions written to help out
    with type converting (obvious) and things like If and Selects.  C has a
    much more limited type comparison set.  Such as switch/case. In C this
    is integer based (which is fine) but in VB select is not.  We will
    have to a set of functions or an engine to handle this.

4 - Others?

just a few things to think about.

scott

On Sun, 19 Nov 2000, Luke-Jr wrote:

> Abhijit Paithankar wrote:
> 
> > pls see message below:
> >
> > > Erm... Fix your clock please? It's not the 20th and if you're in
> > > a different
> > > timezone, shouldn't it put the -0500 or something in the Date
> > > header...
> >
> > Done sir! :)
> >
> > > > > >I think instead of giving 2 options, we could have just a VB2C
> > > > > >interpreter.
> > > > > Anyone looked at this: http://www.naken.cc/vb2c/
> > > >
> > > > It looks OK, but we shall have to request him for the source
> > > code...atleast
> > > > the basic stuff is already present....
> > >
> > > Yup...
> > >
> > > > Since a lot of work is to be done on the GUI/Editor, like being able to
> > > > create a project and work within the project, the toolbars are to be
> > > > emulated, and a lot of other stuff needs to be figured out, the
> > > GUI/Editor
> > > > can be developed independently and then the projectfile shall
> > > be passed on
> > > > to the VB2C compiler....actually, you could download the vb2c
> > > interpreter at
> > > > the URL above, and start off on that.
> > >
> > > Hmm... In that case, I could start on the GUI today... I'm MUCH better at
> > > VB than C...
> > > (I'll just have to remember not to use the WinAPI as I doubt VB2C
> > > will make up
> > > for that for a while...)
> >
> > yes...the earlier the better.
> > also, we could use the latest version of GTK+...just make sure all of use
> > the same versions of any libraries/software we use.
> >
> > For the GUI, I think you should program directly in C on the Linux box. I am
> > really doubtful of how powerful vb2c is at present....would it be able to
> > interpret all those toolbars, and "File Open" dialog boxes and all that?
> 
> Well, nobody said that the GUI had to be compiled until the VB2C part of the
> project was done anyway... Besides, a complicated test program would probably
> be a necessity when working on the VB2C...
> 
I think it best to keep this part of the code as hi-level as
possible.  And again it does not matter if it is not compiled or
compilable for awhile, without a good solid core (vb2c) it's useless
anyway.  The debugger is upfor debate on if it should be in C or
VB.  Though in the Tcl/Tk and Python world their debuggers are mixed.

scott

Anyway, does anyone have a good reason why we shouldn't do everything
in VB4Linux (besides VB2C... for now at least)? Because if there's no
objections, I'd like to get started on the GUI and since we haven't
really decided on a definate GUI interface (GTK+, GNOME, KDE, etc...),
making it in VB would leave that open to modification until we get to
that part of VB2C...

Is there anyone here who has access to a working Visual Basic for
Windows (VB5 with Wine works I think) who also wants to work on the
GUI? Until someone else wishes to do some development with the GUI, I'm
going to keep it to local files... So just email me or the list if you
want to help develop the GUI... Also, I won't start for at least an hour
so that ppl have plenty of time to specify reasons why the GUI shouldn't
be done in VB...

Thx!

Abhijit Paithankar wrote:

> pls see message below:
>
> > Erm... Fix your clock please? It's not the 20th and if you're in
> > a different
> > timezone, shouldn't it put the -0500 or something in the Date
> > header...
>
> Done sir! :)
>
> > > > >I think instead of giving 2 options, we could have just a VB2C
> > > > >interpreter.
> > > > Anyone looked at this: http://www.naken.cc/vb2c/
> > >
> > > It looks OK, but we shall have to request him for the source
> > code...atleast
> > > the basic stuff is already present....
> >
> > Yup...
> >
> > > Since a lot of work is to be done on the GUI/Editor, like being able to
> > > create a project and work within the project, the toolbars are to be
> > > emulated, and a lot of other stuff needs to be figured out, the
> > GUI/Editor
> > > can be developed independently and then the projectfile shall
> > be passed on
> > > to the VB2C compiler....actually, you could download the vb2c
> > interpreter at
> > > the URL above, and start off on that.
> >
> > Hmm... In that case, I could start on the GUI today... I'm MUCH better at
> > VB than C...
> > (I'll just have to remember not to use the WinAPI as I doubt VB2C
> > will make up
> > for that for a while...)
>
> yes...the earlier the better.
> also, we could use the latest version of GTK+...just make sure all of use
> the same versions of any libraries/software we use.
>
> For the GUI, I think you should program directly in C on the Linux box. I am
> really doubtful of how powerful vb2c is at present....would it be able to
> interpret all those toolbars, and "File Open" dialog boxes and all that?

Well, nobody said that the GUI had to be compiled until the VB2C part of the
project was done anyway... Besides, a complicated test program would probably
be a necessity when working on the VB2C...

>
>
> > > Pls check if Wine can emulate the OCX controls...and how do we integrate
> > > them in the code that is to be converted to C...I am still not
> > sure about
> > > this stuff...
> >
> > Wine can emulate OCX controls... There's 2 possibilities for
> > including Windows
> > files:
> >     1. Link a modified version of Wine in with the program and emulate the
> > OCXes only (if possible)
> >     2. Pre-emulate the OCX controls into C code and link a
> > "ported" OCX into
> > the program...
>
> Some team members could do some R&D on this topic. It would be of great
> help.

R&D??

>
>
> ab
>
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev

  -----Original Message-----
  From: vb4...@li...
[mailto:vb4...@li...]On Behalf Of Luke-Jr
  Sent: Monday, November 20, 2000 12:13 AM
  To: vb4...@li...
  Subject: Re: [VB4Linux-Dev] hey I guess so.

  Scott Beasley wrote:
    >how do we divide the work?
    >FROM: Abhijit PaithankarDATE: 11/17/2000
    >I think instead of giving 2 options, we could have just a VB2C
    >interpreter.
    Anyone looked at this: http://www.naken.cc/vb2c/

  Hmm... Maybe we could ask the author if we could use it and upgrade it to
VB.NET...
     show him the bait??  :))))
    >CHM Reader/Viewer and CHM Compiler
    >Syntax colorer and GUI i.e. GUI and the editor
    >VB2C interpreter and Syntax checker
    What about holding off until a base vb2c is done, then code most of the
    tools in the language itself, or do them in VB now and use them as a
test
    for the translator?

  Well, that's what I was originally thinking for the CHM stuff, but I guess
we /COULD/ do everything in VB4Linux... Maybe even rewrite the VB2C once
everything's done so we can say we programmed it in itself. ;-P
       we shall keep upgrading VB2C all the time....so as to make sure soon,
our vb2c would be different from the authors....
    >other tasks like runtime debugger need to be thought of coz` of
    >interpreting, the debugger shall need to reverse-interpret the C code
to
    >VB
    Same as above.

    >at design-time, we can emulate the Win32 API. should we make use of
Wine
    >where?
    >that shall take care of OCX stuff.
    I would use the Wine libs.... saves time and money ;-)

    scott
    _______________________________________________
    VB4Linux-Dev mailing list
    VB4...@li...
    http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev

pls see message below:

> Erm... Fix your clock please? It's not the 20th and if you're in
> a different
> timezone, shouldn't it put the -0500 or something in the Date
> header...

Done sir! :)

> > > >I think instead of giving 2 options, we could have just a VB2C
> > > >interpreter.
> > > Anyone looked at this: http://www.naken.cc/vb2c/
> >
> > It looks OK, but we shall have to request him for the source
> code...atleast
> > the basic stuff is already present....
>
> Yup...
>
> > Since a lot of work is to be done on the GUI/Editor, like being able to
> > create a project and work within the project, the toolbars are to be
> > emulated, and a lot of other stuff needs to be figured out, the
> GUI/Editor
> > can be developed independently and then the projectfile shall
> be passed on
> > to the VB2C compiler....actually, you could download the vb2c
> interpreter at
> > the URL above, and start off on that.
>
> Hmm... In that case, I could start on the GUI today... I'm MUCH better at
> VB than C...
> (I'll just have to remember not to use the WinAPI as I doubt VB2C
> will make up
> for that for a while...)

yes...the earlier the better.
also, we could use the latest version of GTK+...just make sure all of use
the same versions of any libraries/software we use.

For the GUI, I think you should program directly in C on the Linux box. I am
really doubtful of how powerful vb2c is at present....would it be able to
interpret all those toolbars, and "File Open" dialog boxes and all that?

> > Pls check if Wine can emulate the OCX controls...and how do we integrate
> > them in the code that is to be converted to C...I am still not
> sure about
> > this stuff...
>
> Wine can emulate OCX controls... There's 2 possibilities for
> including Windows
> files:
>     1. Link a modified version of Wine in with the program and emulate the
> OCXes only (if possible)
>     2. Pre-emulate the OCX controls into C code and link a
> "ported" OCX into
> the program...

Some team members could do some R&D on this topic. It would be of great
help.

ab

Erm... Fix your clock please? It's not the 20th and if you're in a different
timezone, shouldn't it put the -0500 or something in the Date header... Replies
inside message below:

Abhijit Paithankar wrote:

> > -----Original Message-----
> > From: vb4...@li...
> > [mailto:vb4...@li...]On Behalf Of Scott
> > Beasley
> > Sent: Sunday, November 19, 2000 7:28 AM
> > To: vb4...@li...
> > Subject: RE: [VB4Linux-Dev] hey I guess so.
> >
> >
> > >how do we divide the work?
> > >FROM: Abhijit PaithankarDATE: 11/17/2000
> >
> > >I think instead of giving 2 options, we could have just a VB2C
> > >interpreter.
> > Anyone looked at this: http://www.naken.cc/vb2c/
>
> It looks OK, but we shall have to request him for the source code...atleast
> the basic stuff is already present....

Yup...

>
>
> > >CHM Reader/Viewer and CHM Compiler
> > >Syntax colorer and GUI i.e. GUI and the editor
> > >VB2C interpreter and Syntax checker
> > What about holding off until a base vb2c is done, then code most of the
> > tools in the language itself, or do them in VB now and use them as a test
> > for the translator?
>
> Since a lot of work is to be done on the GUI/Editor, like being able to
> create a project and work within the project, the toolbars are to be
> emulated, and a lot of other stuff needs to be figured out, the GUI/Editor
> can be developed independently and then the projectfile shall be passed on
> to the VB2C compiler....actually, you could download the vb2c interpreter at
> the URL above, and start off on that.

Hmm... In that case, I could start on the GUI today... I'm MUCH better at
VB than C...
(I'll just have to remember not to use the WinAPI as I doubt VB2C will make up
for that for a while...)

>
>
> > >other tasks like runtime debugger need to be thought of coz` of
> > >interpreting, the debugger shall need to reverse-interpret the C code to
> > >VB
> > Same as above.
>
> ya....this needs some ground work to be done before starting off
>
> > >at design-time, we can emulate the Win32 API. should we make use of Wine
> > >where?
> > >that shall take care of OCX stuff.
> > I would use the Wine libs.... saves time and money ;-)
>
> Pls check if Wine can emulate the OCX controls...and how do we integrate
> them in the code that is to be converted to C...I am still not sure about
> this stuff...

Wine can emulate OCX controls... There's 2 possibilities for including Windows
files:
    1. Link a modified version of Wine in with the program and emulate the
OCXes only (if possible)
    2. Pre-emulate the OCX controls into C code and link a "ported" OCX into
the program...

>
>
> ab
>
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev

> -----Original Message-----
> From: vb4...@li...
> [mailto:vb4...@li...]On Behalf Of Scott
> Beasley
> Sent: Sunday, November 19, 2000 7:28 AM
> To: vb4...@li...
> Subject: RE: [VB4Linux-Dev] hey I guess so.
>
>
> >how do we divide the work?
> >FROM: Abhijit PaithankarDATE: 11/17/2000
>
> >I think instead of giving 2 options, we could have just a VB2C
> >interpreter.
> Anyone looked at this: http://www.naken.cc/vb2c/

It looks OK, but we shall have to request him for the source code...atleast
the basic stuff is already present....

> >CHM Reader/Viewer and CHM Compiler
> >Syntax colorer and GUI i.e. GUI and the editor
> >VB2C interpreter and Syntax checker
> What about holding off until a base vb2c is done, then code most of the
> tools in the language itself, or do them in VB now and use them as a test
> for the translator?

Since a lot of work is to be done on the GUI/Editor, like being able to
create a project and work within the project, the toolbars are to be
emulated, and a lot of other stuff needs to be figured out, the GUI/Editor
can be developed independently and then the projectfile shall be passed on
to the VB2C compiler....actually, you could download the vb2c interpreter at
the URL above, and start off on that.

> >other tasks like runtime debugger need to be thought of coz` of
> >interpreting, the debugger shall need to reverse-interpret the C code to
> >VB
> Same as above.

ya....this needs some ground work to be done before starting off

> >at design-time, we can emulate the Win32 API. should we make use of Wine
> >where?
> >that shall take care of OCX stuff.
> I would use the Wine libs.... saves time and money ;-)

Pls check if Wine can emulate the OCX controls...and how do we integrate
them in the code that is to be converted to C...I am still not sure about
this stuff...

ab

>how do we divide the work?
>FROM: Abhijit PaithankarDATE: 11/17/2000

>I think instead of giving 2 options, we could have just a VB2C
>interpreter.
Anyone looked at this: http://www.naken.cc/vb2c/

>CHM Reader/Viewer and CHM Compiler
>Syntax colorer and GUI i.e. GUI and the editor
>VB2C interpreter and Syntax checker
What about holding off until a base vb2c is done, then code most of the
tools in the language itself, or do them in VB now and use them as a test 
for the translator?

>other tasks like runtime debugger need to be thought of coz` of
>interpreting, the debugger shall need to reverse-interpret the C code to
>VB
Same as above.

>at design-time, we can emulate the Win32 API. should we make use of Wine
>where?
>that shall take care of OCX stuff.
I would use the Wine libs.... saves time and money ;-)

scott

Yea... For now just assume it's VB6 with Object Oriented changes... The
VB.NET beta hasn't been released yet so I'll let the list know when it is...

Abhijit Paithankar wrote:

> do we have compatibility for Visual Basic.NET in VB4Linux?
>
> I am signing up for the design/implementation of VB4Linux Windows API Clone
> and VB2C interpreter.
> I shall upload the design documents in a few weeks time.
>
> Pls confirm this, Mike.
>
> Regards,
> ab
>
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev

do we have compatibility for Visual Basic.NET in VB4Linux?

I am signing up for the design/implementation of VB4Linux Windows API Clone
and VB2C interpreter.
I shall upload the design documents in a few weeks time.

Pls confirm this, Mike.

Regards,
ab

we should follow formal UML standards for the project.

Umm... For debugging, I'd think it'd be much easier just to interpret the
VB directly... That way the "Immidiate" window will function correctly...

Abhijit Paithankar wrote:

> I guess so.
> how do we divide the work?
>
> I think instead of giving 2 options, we could have just a VB2C interpreter.
>
> there are some tasks on the task-list that can be clubbed together like:
>
> CHM Reader/Viewer and CHM Compiler
> Syntax colorer and GUI i.e. GUI and the editor
> VB2C interpreter and Syntax checker
>
> other tasks like runtime debugger need to be thought of coz' of
> interpreting, the debugger shall need to reverse-interpret the C code to VB
>
> there are some doubts too:
>
> at design-time, we can emulate the Win32 API. should we make use of Wine
> here?
> that shall take care of OCX stuff.
>
> Also, we can appoint Task-Managers who will be responsible for a particular
> (or a group of) task and then they can think about the way to implement
> their own module.
>
> do we need a website admin?
>
> once we have these things clear, we can start off.
>
> ab
>
> -----Original Message-----
> From: vb4...@li...
> [mailto:vb4...@li...]On Behalf Of Luke-Jr
> Sent: Friday, November 17, 2000 4:52 AM
> To: vb4...@li...
> Subject: Re: [VB4Linux-Dev] hey
>
> Dunno... I guess we should start working on the project? Do we have all
> the plans ready?
>
> Abhijit Paithankar wrote:
>
> > whatever happened?
> > why is everyone so silent?
> > _______________________________________________
> > VB4Linux-Dev mailing list
> > VB4...@li...
> > http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev
>
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev

for GUI development, we have 2 obvious choices

we either use GTK+ which has a good look and feel and also runs on all Linux
distributions, but needs some amount of learning to do before we can build
good interfaces; or we use KDE/Qt which is not all that good with look and
feel, but is easier to code.

Also, take a look at: http://www.fltk.org

I am looking around for stuff on other issues...

2000	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (78)	Dec (11)
2001	Jan	Feb	Mar (10)	Apr	May	Jun (3)	Jul	Aug	Sep	Oct	Nov	Dec
2002	Jan	Feb	Mar	Apr	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec
2003	Jan	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2004	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec

vb4linux-dev Mailing List for Visual Basic for Linux (Page 3)

vb4linux-dev — ML for VB4Linux project developers