Sure! Just send a CR and a drafted FD to make it happen!
Truly excellent suggestions with an explanation as lucid as yours are always honoured instantaneously ;-)

Keep on!

A1880

Hello at all, i'm new to jabaco and is fantastic RAD ....
i want to know if jbaco is active project or not and about new version.


thanks very much.

i'm working on the next version and i'll reconcentrate on this project in near future. the next version will improve the design editor and things like that. suggestions and reports are very welcome in the community.

Hello, Manuel,

Quoted from "Manuel"

i'm working on the next version and i'll reconcentrate on this project in near future. the next version will improve the design editor and things like that. suggestions and reports are very welcome in the community.

Wanted to know if you could improve Jabaco to handle mobile development, like was mentioned before ("to support the development for mobile phone devices in Jabaco, the Jabaco compiler needs an additional compiler step: Preverify")


Please send you comments about how could Jabaco be configured to handle this, when possible too...



Regards,

Sven

Whoops! I accidently clicked "Report" instead of "Reply" on Sbleck above message. Sorry!



Anyways, I think there is a real market for a mobile development RAD. Jacabo would be the perfect RAD for developing Android (Phone and Tablet) and Blackberry applications. On the desktop, there is a lot of competition for RAD's but for the mobile development field there are few options.

I would like to see Jabaco allow in-line java code so one can easily do such things as using thrid-party classes eg
http://quicktable.org/#dbgrid


I am new to Jacabo so if it can already please show a small example code


Many thanks

Quoted from "A1880"

Sure! Just send a CR and a drafted FD to make it happen!
Truly excellent suggestions with an explanation as lucid as yours are always honoured instantaneously ;-)

I think he is referring to todo and issue databases. Perhaps we can "borrow" such modules from Eclipse?

On the other hand i would prefer the IDE to be lightweight and not as bloated as other IDE:s tend to be. Such functionality should possibly be handled outside the IDE.

Also I stand in line for a stable commercial version. What we need is not more beta features, we need a stable version so we can go commercial with the current features.

Sorry for my somewhat ironic post from January.
Some suggestions are simply a bit too far-reaching and lack any sound reasoning.

I am wondering if there will be a new version at all in the foreseeable future.
Jabaco is quite complex, and there is still only one developer behind it.

It would help to get some volunteers to straighten out the missing bits and pieces in the framework.

Greetings

A1880

Hi A1880, Hi Faldegast



you both mentioned the point, we really got to talk about since long ago!

I totally agree with Faldegast:

Quoted

Also I stand in line for a stable commercial version. What we need is not more beta features, we need a stable version so we can go

already here comes the Jabaco-Framework into play!

Tha Jabaco Framework already is *the* huge Jabaco project that can only be maintained with the massive help of the Jabaco IDE.

To stabilise and utilise the work with the Jabaco-project-file should be the starting point for development with the highest priority!



At the moment the Jabaco-Framework contains two projects into one:
* the Jabaco-Framework as is, and
* a project for testing the Jabaco framework.

so the Jabaco project file needs the ability to handle this.



Moreover the Jabaco Framework is made of

* Java and
* Jabaco sourcecode

and it would be best to make it possible to compile Java and Jabaco source together with a single compiler.


regards

OlimilO

Automatic recompilation of Jabaco classes is not feasible for the time being.
A commandline version of the compiler is necessary to integrate compilation in ant or make scripts.
Possibly, one could use automation tools like AutoIt3 to run the Jabaco IDE in a scripted fashion.
But that's probably a rather bizarre way of doing things.

Personally, I don't intend to use Jabaco commercially but rather take it as an intellectual exercise.
Jabaco is related to many current technologies and it is fun (at times ...) to solve upcoming
Jabaco questions.

I would not recommend to declare the beta phase closed.
The reason is, that there are still many open issues (WINAPI, file handling, exception handling, GUI design,
compilation errors, array handling, ...).
Jabaco IDE and framework are not mature enough to be of real value in commercial projects.
For experiments and self-learning, Jabaco definitely has its merits, but I would not bet the fate of my company on it yet.

Greetings

A1880

Quoted

Automatic recompilation of Jabaco classes is not feasible for the time being.

sorry, what are you talking about?

Quoted

A commandline version of the compiler is necessary

Jabaco *is* already runnable by commandline.

Quoted

to integrate compilation in ant or make scripts

the Jabaco-compiler at Google-Code does already run by an ant-script.
But in my opinion it's simply not comfortable enough, to maintain the Jabaco-Framework in this manner

*schauder*

But OK, ... the situation is like a dragon that bites itself in his own tail

regards

OlimilO

Where can I find information on the commandline mode or the commandline compiler?
I haven't been aware of this feature. Maybe, because I am no framework developer.

Greetings

A1880

Ant needs a build.xml

You can find it on GoogleCode in the Jabaco-Framework-Sources here:

http://code.google.com/p/jabacoframework…ework/build.xml



the desired information can be found in this section here:


when we extract the useful informations we get:

JabacoDir\Jabaco.exe -projectpath=ProjectDir\MyJabacoProject.jba -d=BuildDir



regards

OlimilO

Thanks for this hint!

I've written the following cmd file "build.cmd":



Compiling a project with a deliberate fault, I get a log file "build.log" in my output directory ".\classes":



Compilation stops at the first error. This is fair enough for compilation of tested components.
The error location is nicely communicated in the log file.

All in all, the commandline mode works quite well.
I've noticed that it takes several seconds to load Jabaco.exe before compilations starts.

Greetings

A1880

As you can see here:

http://www.jabaco.org/framework.html

the Jabaco-Framework does not completely compile any more. the Jabaco-source part is missing.

in the log file the last entry is:

20XX-XX-XX STATE: Init GUI-Editor...

then compilation dies before it really starts.

maybe something in the project file Framework.jba is missing, or maybe something is not in the right order anymore... don't really know. The Project file is rather huge because of the massive namespace-imports.

regards

OlimilO

Yes, I've noticed that recent framework download files are too small to be complete.

Would it make sense, as a workaround, to compile the framework in two or more parts and merge the resulting classes afterwards?

Happy compiling!

A1880

Quoted

when we extract the useful informations we get:
JabacoDir\Jabaco.exe -projectpath=ProjectDir\MyJabacoProject.jba -d=BuildDir

Thanks for that info, OlimilO.

Quoted

As you can see here:
http://www.jabaco.org/framework.html
the Jabaco-Framework does not completely compile any more. the Jabaco-source part is missing.

I will later have a look at it.
Currently it only don't compile with ant. The older way still works. The last revision have had only problems, because Franco addeed files, which wasn't added in the FrameworkTest.jba. So it needs only a minor change, which I have now done.
So, to compile the Framework in the old way is still possible and easy.
If you have problems to compile it, please publish here, what errors comes.

Only the ant-way don't work currently.


And now to A1880:

Quoted

Would it make sense, as a workaround, to compile the framework in two or more parts and merge the resulting classes afterwards?

What do you mean with it?
Why compiling in parts. Currently there existing two steps to compile:
1. compiling the Java-sources in VBA
2. compiling the Jabaco-sources in VB

thats it.

By compilation in parts I mean the following:

One could try to split the Jabaco framework classes in two or more independent sets
where no class in set A refers to a class in set B and vice versa.
The next step would be to compile the resulting sub-projects (one project per set).
Finally, the generated class files have to be merged into one Jabaco.jar framework library file
using copy commands and the jar archiving tool.
Whenever a change occurs, only the respective sub-project has to be recompiled.
This speeds up recompilation of the framework during testing.
Another advantage probably is the reduced amount of resources (memory, disk) to
perform a compile step.

What do you think?

Is Jabaco.exe clever enough to do a conditional compilation where only those classes
are (re-)compiled which have sources more recent than the (already existing) binary class files?
This obviously would blow the idea of partial compilation.

Greetings

A1880

Quoted from "A1880"

What do you think?

It sounds a little bit like Jigsaw in JDK7.
But at the end it is completely different and I think it would have more disadvantages then advantages.

The advantage:
- "This speeds up recompilation of the framework during testing."
- "Another advantage probably is the reduced amount of resources (memory, disk) to
perform a compile step."

The disadvantages:
Instead of one *.jba file to compile you have a lot of them.
This means
- if you have imported a class of the JDK in the class-browser (for example java/awt/event/WindowEvent), it is possible that it is not imported in all *.jba files. So depending on, which *.jsrc is part of which *.jba, you can call WindowEvent direct or you have to write java#awt#event#WindowEvent.
- because there are more then one *.jba files, all have to be loaded successively. This means, the first compile would need longer, then at the current situation.
- Normally you don't write a *.jsrc file in a text-editor. But if the framework is splitted, then you don't have all Jabaco-files of the framwork at once in the Jabaco IDE. Some people want a Java-source support in the Jabaco IDE to have all at the same time together. If one file can't compile, because in the other file is a bug, then its easier to change to the other file. But you want to create more project files.
- If you say "then let us create the mini *.jba projects beside the Framework.jba where still all is in it", then there is the problem to handle multiple *.jba files, which makes use of the same *.jsrc files. And so you have synchronal change some .jba files, which makes the work not easier.

I think it would be easier to write in the complete Framework everytime the full name of classes (for example "java#awt#event#WindowEvent" instead of "WindowEvent". In this case the *.jba file is not needed and it would be possible, that Manuel creates a compiler which compiles a *.jsrc file direct.
So in this case you can compile the framework file by file.Only a Makefile or Ant-file is needed, to compile the *.jsrc files in the right order.