>Yeah !!! But how do you structure files of a stack ????
Hi,
the file format stacks will be kept in is that of XBF (on the web site).
Though the version of XBF that will finally be used will allow having
blocks that "belong" to another block. Then a button's block would belong
to the block in which the card it is on is stored. If you need to change
any code, be sure to note down somewhere what you change, since I'm working
on implementing sub-blocks currently and I'll then have to copy whatever
you change into my sources.
>In fact it's very difficult to have a commun code which work on Mac and
>Wintel
>Most of the you found the heart of the app in standart C or C++ wich can be
>easily
>compiled on each platerform but for the user interface you find TWO codes :
>one for the
>Mac and one for the WINTEL.
>The rarely application who User Interface encapsuled for Wintel and Mac are
>very difficult
>to write and mostly very heavy and slow...
You're of course right. But for a cross-platform product it is necessary
to have as much common code as possible.
>Hum, it's theoricly possible, but in pratice it will be diffucult because
>i'm not
>living with my little sister ....
Oh. Ok. Then we'll probably have to send across screen shots if we need to
check whether the two versions match.
>OK, i have started to download the sources code on the FTP site. I will try
>to take a look and compile it under CodeWarrior or Visual C++ on my PIII
Great, thank you very much.
>OK i note this. I will be thinking about all these things, But Now i must
>take a look a the code already
>exist, try to use it, and
So you're going to make the Windows port. OK. The other stuff was just a
couple of options we could add in.
>What option have take ???
>To have the exactly same interface on the two plateformes
>or, like Omnis or 4d, the application adapt the look of the button to the
>user guidelines of each plateform ????
>
>Personnaly i'm prefer to maintin the specificity and guidelines of each
>plateforms!
It's our plan, too, to try to have FreeCard look native on every platform.
That is we don't want it to look like a ported Macintosh application. It'll
have multiple menu bars on Windows, will use rectangular Windows buttons
there, etc., while on the Mac it will look pretty much like HC does now. Do
you have any ideas how we could implement the menus? We can't give each
stack its own menu bar, as HC allows to have one stack that creates the
menus for the others. OTOH a shared menu bar under Windows sounds like a
waste of space. I guess we'd have to add a property like "sharedMenus"
which is true by default?
>If you read my upper respond you will understand which aspect interrest me.
>In fact trying to do a part of the translation under the win NT (if my next
>test
>to compile source code succes !!!)
I wish you godspeed :-)
>! As for coding style: Add many comments, rely only on ANSI C++ calls and
>!abstraction-layer classes, and don't introduce any limits besides what the
>!system has (e.g. using bigger values than longs is not necessary, as RAM
>is
>!currently limited to a long's size, anyway... etc.).
>--
>Well i have notice that !
But of course the code shouldn't rely on them staying a long, that is,
define a typedef for every type you use, or use existing ones like size_t
which aren't guaranteed to stay a long, and use the sizeof() operator
instead of hard-coding 4 when you need their size, so we can easily
re-define the type to allow a larger size.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
--- HELP SAVE HYPERCARD: ---
Details at: http://www.hyperactivesw.com/SaveHC.html
Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
