headers
Martin Schreiber | 2 Jan 2010 12:01

MSEide+MSEgui rev. 2.2 for FPC 2.4

Hi,
MSEide+MSEgui version 2.2 for FPC 2.4 has been released:
https://sourceforge.net/projects/mseide-msegui/files/

There is now an experimental x86-64-linux version too.

Have a lot of fun!

Martin
Permalink | Reply | 20 comments |
headers
IvankoB | 3 Jan 2010 01:03
Picon
Favicon

Re: MSEide+MSEgui rev. 2.2 for FPC 2.4

> Hi,
> MSEide+MSEgui version 2.2 for FPC 2.4 has been released:
> https://sourceforge.net/projects/mseide-msegui/files/
>
> There is now an experimental x86-64-linux version too.
>
> Have a lot of fun!
>
> Martin

A new year edition :)
Me see huge advancement in the IFI area & it's not optional by default 
anymore, what's interesting there ?
Permalink | Reply | 19 comments |
headers
Martin Schreiber | 3 Jan 2010 09:18

Re: MSEide+MSEgui rev. 2.2 for FPC 2.4

IvankoB wrote:

> Me see huge advancement in the IFI area & it's not optional by default
> anymore, what's interesting there ?

The following is in trunk only:
MSEifi has been divided into the existing remote components with
serialisation which can work over pipes, sockets or internet connections
(compile with mse_with_ifirem in order to enable) and a new "another modern
abstraction layer" ;-) in order to separate GUI and business logic.
tifi*linkcomp are like taction for data edit widgets. Place them into the
business logic datamodules and connect the t*editwidget.ifilink properties
of the GUI.
Experimental and not finshed at the moment. Please write if you are
interested in such a development.
BTW, all this experiments showed, that the possibilities to build
sophisticated GUI with strict separation of all logic and display data
generation from GUI are limited. Either it does not provide the needed
functionality or the business logic must know so much about the GUI so it
doesn't make sense to implement all display and editing functions in data
modules and use cumbersome and limited remoting.
So I think for many applications it is still the best to use datamodules for
DB access and business logic and forms with eventhandlers for the low level
GUI.

Martin
Permalink | Reply | 18 comments |
headers
Michael Schnell | 3 Jan 2010 12:11
Picon
Favicon

Re: MSEide+MSEgui rev. 2.2 for FPC 2.4

Very intersting.

I really need to take another look at MSEifi.

-Michael
Permalink | Reply | 12 comments |
headers
Michael Schnell | 3 Jan 2010 12:20
Picon
Favicon

Re: MSEide+MSEgui rev. 2.2 for FPC 2.4

Martin Schreiber wrote:

> BTW, all this experiments showed, that the possibilities to build
> sophisticated GUI with strict separation of all logic and display data
> generation from GUI are limited. Either it does not provide the needed
> functionality or the business logic must know so much about the GUI so it
> doesn't make sense to implement all display and editing functions in data
> modules and use cumbersome and limited remoting.

I did take a look at Sliverlight/Moonlight, which seems interesting for 
pascal programmers since Delphi Prism is available.

Here seemingly the "Body of the application" and the "Gui related parts 
of the application" can be separated at any layer the programmer 
chooses, with the "Body of the application" running on the server (which 
hopefully provides fast execution of the business logic) and the "Gui 
related parts of the application" run within a browser, thus "near to 
the GUI" and hopefully provide fast GUI interaction.

Thus a future version of MSEGui that can compile to CIL Assemblies 
(".Net executables") might be an nice option :) . Unfortunately the FPC 
community is not interested in CIL :( .

-Michael
Permalink | Reply | 4 comments |
headers
Administrator | 3 Jan 2010 20:46
Picon
Favicon

Re: MSEide+MSEgui rev. 2.2 for FPC 2.4

I got an error while compiling MSEide with FPC 2.4.0
(Windows).

Free Pascal Compiler version 2.4.0 [2010/01/04] for i386
Copyright (c) 1993-2009 by Florian Klaempfl
Fatal: Can't find unit FPimage used by msegraphicstream
Fatal: Compilation aborted

I see in FPC 2.4.0 source that the filename of fpimage is
"fpimage.pp" and the unit name is "FPimage".

How to fixt it?

Thanks
Permalink | Reply | 3 comments |
headers
IvankoB | 3 Jan 2010 22:52
Picon
Favicon

Re: MSEide+MSEgui rev. 2.2 for FPC 2.4

> Free Pascal Compiler version 2.4.0 [2010/01/04] for i386
> Copyright (c) 1993-2009 by Florian Klaempfl
> Fatal: Can't find unit FPimage used by msegraphicstream
> Fatal: Compilation aborted
>
> I see in FPC 2.4.0 source that the filename of fpimage is
> "fpimage.pp" and the unit name is "FPimage".
>
> How to fixt it?
>
>

A known issue when bulding a newer FPC version using older current one :)
As the result, You've mixed 2.2 & 2.4 FPC units, adjust the config files and 
rebuild FPC.
Permalink | Reply | 0 comments |
headers
Martin Schreiber | 4 Jan 2010 07:02

Re: MSEide+MSEgui rev. 2.2 for FPC 2.4

Administrator schrieb:
> I got an error while compiling MSEide with FPC 2.4.0
> (Windows).
> 
> Free Pascal Compiler version 2.4.0 [2010/01/04] for i386
> Copyright (c) 1993-2009 by Florian Klaempfl
> Fatal: Can't find unit FPimage used by msegraphicstream
> Fatal: Compilation aborted
> 
Works for me.
> I see in FPC 2.4.0 source that the filename of fpimage is
> "fpimage.pp" and the unit name is "FPimage".
> 
> How to fixt it?
> 
fpc-2.4.0.i386-win32.exe installs into a 2.2.4 folder by default. Did 
you rename the folder after installing FPC? Check if the path settings 
in <FPC directory>\bin\i386-win32\fpc.cfg are correct.
Compile with -vu in order to check which unit files are loaded.

Martin
Permalink | Reply | 1 comment |
headers
Administrator | 4 Jan 2010 09:47
Picon
Favicon

Re: MSEide+MSEgui rev. 2.2 for FPC 2.4

I compiled FPC 2.4.0 from source. And after I download FPC
2.4.0 binary, and I remove old FPC, this problem doesn't
show again. Maybe Martin and IvankoB are right, when old FPC
exist, the units is taken from fpc.cfg.

Thanks
Permalink | Reply | 0 comments |
headers
IvankoB | 4 Jan 2010 15:26
Picon
Favicon

Re: Decision on help file format ?

> I have detailed documentation on the INF file structure and already
> translated data structures in Object Pascal if you are interested. I'm 
> also
> nearly finished with the 'docdump' tool that outputs the INF file 
> structure
> with data for any given INF file (very handy for debugging read/write
> issues with INF format).
>

Me can't get any info (in the escape sequences) on decoding 
[un][ordered]lists :)
Where to stare for them in the DOCVIEW sources ?

BTW:

1) Your decision to hold full link definitions in memory so that rich 
strings (& images ?) only refer to IDs of these definitions looks excellent, 
w /o that the things were barely differ from the usual (though a bit 
truncated) HTML.

2) it seems that the (only) delay when starting DocVIew is a result of 
loading + decoding global dictionary.

3) what is the reason to keep local (per-cell) dictionaries which just hold 
intemediate indexes to wods in the global dictionary, what do You think ?
Permalink | Reply | 1 comment |

Gmane