One thing I'm not quite clear about (and will assume that others are equally unclear) is the distinction between projects and programs in the Editor. As I understand it, the basic working unit will be a "project" (or perhaps we should call it a "solution" using the Visual Studio .NET name.) In the typical VB environment, the output of a project is a single EXE or DLL, created from various source code modules. But in the typical AlphaBasic environment, the output might either be a single RUN, or a collection of RUNs which together make up a module (e.g. Receivables, General Ledger, Inventory, etc.), or all of the RUNs for all of the modules, probably numbering in the hundreds or even thousands. Typically there is only one BAS file per RUN, but many includes (and SBX modules?) which are shared between the programs.

So I'm wondering what the optimum working unit will be for the Editor. If it is just a single program, then we will end up with hundreds of "projects". But if it is a collection of programs which make up an entire application, then this may complicate both the pre and post compile operations, as well as questions of sharing/locking between multiple programmers working on the same application.

Obviously, you have the same kinds of locking/sharing issues with VUE, but in that case, an individual programmer is likely to be editing only one file at a time, whereas with the Editor, you may have open (possibly read-only?) all the files which together make up one (at the least) or perhaps hundreds of programs. The Editor is not a source code management system, but it should ideally be compatible with one (whether based on a formal product, or just a set of procedures followed within a company).

I bring this up, because it may be that the best way to handle this is to add a hook for a command or script to be executed when opening and closing the project (analogous but on a higher level to the what we have been talking about for the pre and post compile commands).

Once inside the Editor, the first unit there is a Project where you add files.
Files in a Project could be:
- anything editable by the Editor but, it will not be a good idea to add an INCLUDE file to the Project (more details ahead)
- screen files created in the Editor
- any file editable in Windows applications (Word, Excel, Images,...)

The concept of a project in the editor is to group files with relations between them but, one file could exist in different projects.

Let's look at some possible scenarios.

a)
If I'm the responsible to design software specifications on my company and prepare the work for programmers and have a new "project", I could:
- on the Editor, I'll create a new Project named "new program for customer x"
- on the Screen Editor, I can design some of the screens I want to be created and save them in the project
- in Word I can write specifications about the new program and include that file in the project
- if I want the programmer to use some specific SBX files that already exist or even create in advance some SBX for the program, I can include those files in the project

Well, what is missing here?
The program(s) I want the programmer to write but, I can prepare a lot of the work in advance.

After the program finished, the Project could be kept with the initial specifications and the final result but, if the program belongs to an application, let's say, Inventory Control, probably should exist a Project named "Inventory Control" so, the BAS and SBX used on this new program should be added to it.

b)
If I'm starting to convert my programs to GUI, I can create a project named "GUI" and start adding there the programs I'm working.

What about the INCLUDE files ?
Don't need to be add to the project because, when the BAS file is opened they will be considered like a structure inside the program with easy access for editing.

Additional notes:
- each file included in a project can be in different folders and searched by UNC,DEVICE or ERSATZ
- the Project doesn't contain each file inside it, just a reference to it and, that's why one file can be in different opened projects but, edited just by one person
- projects can have pre and pos-compiler settings that will be common to all the BAS files included in the project
- the Project concept doesn't affect anything on the files it's just a way to group related files and define common specifications
- if I don't need to edit SBX called from a program, I don't need to add the SBX file to the project
- RUN files are not included in projects
- when I mentioned SBX files above, I mean BAS sources for SBX files not the SBX itself

Well, I guess that, if I continue, probably will confuse more than clarify so, let's see if the above notes were helpful and wait for your comments.

Regards

Jorge's example of the project concept fits my idea of what it should be.

The proposed project setup looks great. I like only one person editing a file at a time. I would like a more formal library system so source files are assigned to particular users and can only be changed by them. This goes for includes as well. This avoids a problem where a programmer comes in after hours or works from home and takes a look at a program, only to accidentally mess it up, finish instead of quit due to loack of sleep, and now the source is bad .

Well Mike, your concerns are real but I think that have more about General System Security than about the Editor itself.
In fact, on our list of features is the user/password access to projects maybe even files but, don't forget that, each file (with programs source code) in a project can always be opened with the VUE or NOTEPAD or anything that opens text files.
Will we need to use some encryption there ?
Don ? does your ISO specifications compel you to also encrypt the sources ?

Regards

First, to speak for Don on the encrypted files - in fact, they do encrypt all of their source code. (Logging in to their app establishes the key in memory, and then VUE uses it to encrypt/decrypt, making the process more or less transparent to the programmer.) But that encrypted file system (which we call EFS) is only currently available for Linux. In any case, I think we are getting a bit off the track here.

To get back to Projects, what you described is pretty much what I think most people want. But I am still a bit unclear about whether there are two levels of compile - one for a specific BAS file, and one for the project (which many contain many source files, some of which are SBXs, etc.) I think it would be nice to be able to build a master project, say, Inventory Control, from which one could press a button to "rebuild entire project" i.e. run a command file or script to recompile all the modules.

For a mature project (again, using Inventory Control as an example), if the programmer/analyst wanted to consider the possibility of adding a feature, it would be nice to open the Inventory Control Project in the Editor, from which point you could use the various features of the Editor to jump around from one BAS program to another, first to decide what needed to be done, then later to actually implement the feature. While doing this work, the programmer might want to be able to compile and test a single program at a time, or, if a common MAP or BSI was changed, to recompile the entire project.

I guess my issues/concerns were that if you did open up a large project like this:

1) You would want a mechanism similar to the pre and post compile that would allow for a script to be executed to perform some kind of check-in / check-out for the entire project (pre-open of the project and post-close), plus some way of combining all the compile commands for the various RUN and SBX modules within the project.

The pre-open-project script could be customized by the user to interface with a source code management system, or to do create "project-in-use" semaphore, or to copy files from a server to the workstation, or to interface with some kind of programmer billing system, or nothing at all. Likewise for the post-project-close script.

2) Although opening a project wouldn't necessarily open every file in the project, if you wanted to use an editor feature, like locate all the source code lines that used a certain common MAP variable, then it would have to open all the files to search for it. It would be nice to have some kind of read-only feature, so that if two programmers were working on the Inventory Control project, and a true source code management system was NOT being used, then at least when one programmer opened a file to make changes, the other would perhaps be able to search through that file but not be able to make changes.

I'm guessing that you can do this just like VUE does, i.e. put a lock on the file when opening it to make changes. (That would also eliminate the concern of some VUE or another editor thinking it could change a file that was in use by the A-Shell Editor.) But I'm not quite sure what the best way to decide when you wanted to lock a file was. For example, just because I open the Inventory Control project doesn't mean I want to make changes to every (or even any) of the files in it. One solution would be to have a keyboard or mouse command to open a source file for changes (which placed a lock on it, or reported if the lock was not available). Or, perhaps locking the file for read/write access would be automatic when you made it visible in the main editing window, but not necessarily when you were simply searching the project for instances of a variable.

I don't really want to complicate the Editor with a lot of extraneous issues, but I think we have to take into account that most programmers are working with large groups of programs, and we need to both provide the necessary hooks for them to be able to do what they currently do with the combination of VUE and CMD/DO files, and also to draw the line between the responsibilities of the Editor and the responsibilities of the system administrator / locking system / source code management system / etc.

I agree with you about have batch commands doing the same that will be done in a single opened program like, find, replace, compile and so on.
And for that purpose it will be considered three levels for the files under those processes:
- single opened file
- multiple opened files
- all files in a project
Considering the compile example, it will be possible to compile the program opened, all the programs opened or all the programs in the project in use.
That's the idea but, some complications will arrise with the error list if an error exist in an include file common to almost all programs. Probably, when compile in batch mode, the main error list should only report the programs with errors and selecting one from that list will open the program and the correspondent error list.

As an aside, it would be interesting to know, wich method(s) should be used to fill projects with files, mainly for the initial projects:
- all programs in a folder ?
- an "open" dialog with multi-selection ?
- use a filter with wildcards like STK???.BAS ? and with confirmation ?

About the control of files in use, something must be done for sure, I must analyze this with Filipe but, I know what I would like to have that is, visualy identify wich files in a project are in use (different colour on the icon or some signal like a cross for example).

Still about compilation, now, we use F5 for generate RUN files and F6 for SBX but, obviously this is not the desired option for this and even less if we consider the batch compile. What I have in mind is, in some way signal SBX and F5 will know wich are RUN and SBX. Any suggestion for how to signal the files or a different method to handle this ?

Of course that, everything multi-something complicates but that's how things work so, solutions must be found.

Regards

On the question of how to initially add programs to a project, I think the multi-selection file open dialog is sufficient. After all, the user can use wildcards within the dialog to limit the files being shown, and then use Shift and Control Click operations to quickly select large numbers of files.

On the issue of how to know when a BAS should be compiled to RUN or to SBX, someone at the Conference (Herman I think) came up with the best suggestion - add a ++PRAGMA to the top of the SBX source code, i.e.:
Or perhaps
This would tell the compiler to rename the output to .SBX instead of .RUN.

This brings up the question of what if not all programs within a project use the same compiler switches? Is this an issue? I don't think so, because the most likely switch that would change is /A (or /AV), and those are now automatic. If /M is not used throughout (as it should), then it can be activated or deactivated by ++PRAGMA ERROR_IF_NOT_MAPPED "ON"/"OFF".

The one switch which cannot be turned on/off with a ++PRAGMA is /X, since it requires at least /X:1 to recognize ++PRAGMA. But for anyone likely to be interested in this level of sophistication, I can't see any reason not to always use /X:2.

While we on the PRAGMA issue, im unable to get the compile to recognize it with /X:1 or /X:2

Maybe im still jet lagged and not doing something right!

My really simple example:
STEVE.BAS
++PRAGMA SBX
PRINT "HELLO"

COMPIL STEVE/X:1 (or /X:2)
and I get:
Phase 1 - Initial work memory is 7088 bytes
?Bad ++PRAGMA option (1) - ++PRAGMA SBX
Phase 2 - Adjust object file and process errors

Ideas? or am I jumping the gun and its not implemented yet!

Why not use the AMOS model of [project,programmer] account numbers? I am sure that many of us either have our AMOS projects in a single PPN [P,PN] or a single project [P,*]. The OPEN dialog gives maximum flexibility but I think it would be good to have the choice to fill a project either from [P,PN] or [P,*]. This could be an extension to the wildcard filling mentioned above: just add [P,PN] to the filter.

Of course, it is possible to have duplicate program names over [P,*], so there's another issue that should be addressed. Perhaps the PPN should be part of the filename in the editor's project control file (if it isn't already, either as adding the relative path to the file or in AMOS nomenclature.)

We also need a way to differentiate between an editor project and an AMOS project in the PPN, or at least I do. I confused myself at least twice writing this note!

Steve - yes you are jumping the gun on the ++PRAGMA SBX. Maybe I'll implement it today, which would mean 906-3 at the minimum.

OK, me being about 8 time zones ahead I thought it was done. no hurry.

906.3, just now posted, supports the SBX pragma. See the ash49devnotes for details.

Thanks, i'll give it ago tomorrow as the work day is closing in on me.