vb4linux-dev Mailing List for Visual Basic for Linux (Page 3)
Status: Planning
Brought to you by:
luke-jr
You can subscribe to this list here.
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
|
From: Abhijit P. <abh...@ma...> - 2000-11-20 15:06:43
|
any idea how we could reuse the existing WinAPI for VB? |
From: Scott B. <js...@go...> - 2000-11-20 13:32:00
|
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 > > |
From: Scott B. <js...@go...> - 2000-11-20 13:27:43
|
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 > |
From: J C. <ja...@st...> - 2000-11-20 09:56:22
|
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? |
From: Abhijit P. <abh...@ma...> - 2000-11-20 08:09:07
|
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! > |
From: Abhijit P. <abh...@ma...> - 2000-11-20 08:08:55
|
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. |
From: Luke-Jr <Mi...@an...> - 2000-11-20 04:50:02
|
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 |
From: Luke-Jr <Mi...@an...> - 2000-11-20 04:47:02
|
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 |
From: Abhijit P. <abh...@ma...> - 2000-11-20 03:38:30
|
> > 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 |
From: Luke-Jr <Mi...@an...> - 2000-11-20 00:49:35
|
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 |
From: Scott B. <js...@go...> - 2000-11-20 00:14:45
|
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 |
From: Scott B. <js...@go...> - 2000-11-19 23:13:37
|
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 |
From: Luke-Jr <Mi...@an...> - 2000-11-19 20:04:52
|
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! |
From: Luke-Jr <Mi...@an...> - 2000-11-19 19:49:29
|
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 |
From: Abhijit P. <abh...@ma...> - 2000-11-19 19:34:48
|
-----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 |
From: Abhijit P. <abh...@ma...> - 2000-11-19 19:34:46
|
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 |
From: Luke-Jr <Mi...@an...> - 2000-11-19 18:48:17
|
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 |
From: Abhijit P. <abh...@ma...> - 2000-11-19 16:54:54
|
> -----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 |
From: Scott B. <js...@go...> - 2000-11-19 15:41:32
|
>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 |
From: Luke-Jr <Mi...@an...> - 2000-11-19 12:34:35
|
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 |
From: Abhijit P. <abh...@ma...> - 2000-11-19 05:09:40
|
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 |
From: Abhijit P. <abh...@ma...> - 2000-11-18 07:05:16
|
we should follow formal UML standards for the project. |
From: Luke-Jr <Mi...@an...> - 2000-11-17 19:16:40
|
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 |
From: Abhijit P. <abh...@ma...> - 2000-11-17 16:27:56
|
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... |
From: James C. <ja...@st...> - 2000-11-17 15:06:31
|