realbasic-nug
[Top] [All Lists]

Re: File Suggestions?

To: REALbasic NUG <realbasic-nug@lists.realsoftware.com>
Subject: Re: File Suggestions?
From: "Rubber Chicken Software Co." <support@chickensys.com>
Date: Tue, 28 Apr 2009 17:42:47 -0500
Authentication-results: mx.google.com; spf=neutral (google.com: 74.124.194.228 is neither permitted nor denied by best guess record for domain of realbasic-nug-bounces@lists.realsoftware.com) smtp.mail=realbasic-nug-bounces@lists.realsoftware.com; domainkeys=neutral header.From=support@chickensys.com
Delivered-to: listarchive@realsoftware.com
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=chickensys.com; h=Received:X-Mailer:Date:To:From:Subject:In-Reply-To:References:Mime-Version:Content-Type:X-Identified-User; b=hR/svdpRNiUTRmGUN6RzEcxbFwAYAxbCTX9u5nUd483yeyTk9AJ/A95UxO/htTFLHQ53XCtjSm/h2L0Qjf3ugDFQ3Ev+vsb0Icaf480OY89xdBsUWpiuiTe+7VvpOpLa;
Domainkey-status: unknown
In-reply-to: <C0078643-184D-4811-BEBB-A7CEE419C1D8@elfdata.com>
References: <mailman.1.1240945205.15355.realbasic-nug@lists.realsoftware.com> <C0078643-184D-4811-BEBB-A7CEE419C1D8@elfdata.com>
Reply-to: REALbasic NUG <realbasic-nug@lists.realsoftware.com>
Sender: realbasic-nug-bounces@lists.realsoftware.com
At 04:07 PM 4/28/2009, you wrote:

The main thing is to make your format extensible. Thats what XML is about...

Most native binary formats end up "painting themselves into a corner",
not allowing themselves to add extra information at a later stage.
Instead of having a hierarchical and extensible format like XML.

There are binary XML libraries around that could be turned into a
plugin, although I'll bet it's much easier to write your own binary
XML in REALbasic, or just use sqlite :)

Well...

As someone who makes living interpreting file formats...

Most data file formats, before XML, were binary. There never was a need to "open up the file and read it" with your own eyes. Most often things were IFF based, meaning you had a 4-byte tag, followed by a 32-bit size, then a chunk of data. You can nest and everything.

With the advent of the web, HTML, and XML, now (at least in my industry, music) file formats are going more "text based". But you still have to deal with binary data. Data like pictures and sound are binary creatures. So ultimately your files ends up being a touch text and whole lotta binary.

But the built in classes for XML in RB are real nice and gives you a framework.

Now, I wouldn't agree with the statement "Most native binary formats end up "painting themselves into a corner", not allowing themselves to add extra information at a later stage." XML has the same problem, does it not? Any IFF-based binary file has a size parameter for each chunk, and you read it, but you have to interpret the bytes in the chunk you are reading. You have to do the same in XML. The only difference between XML and IFF is one is text-only and the other is not. XML can nest infinitely - IFF can too.

You can either choose to embed the picture data, or have a small data file that references external picture files. If you choose to embed the picture data, I like the idea of something like <data>[base64 encoded data]</data> whenever you need data.

* * * * * * * * * * * * * * * * * * * * * * * * * * *
| Garth Hjelte                                      |
| Customer Service Representative, President        |
| Chicken Systems, Inc, Rubber Chicken Software Co. |
| 714 5th Street SE                                 |
| Willmar, MN 56201 USA                             |
|                                                   |
| 800-8-PRO-EPS    Toll Free Order Line (US Only)   |
| 320-235-9798     Tech Support, Sampler Questions  |
|                  International Line               |
| 360-838-7689     Fax                              |
| Product Sales:   sales@chickensys.com             |
| Product Support: support@chickensys.com           |
| Sampler Q+A:     qa@chickensys.com                |
| Web Page:        www.chickensys.com               |
* * * * * * * * * * * * * * * * * * * * * * * * * * *


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>


From  Tue 28 Apr 2009 18:28:54 -0500 (CDT)
Delivered-To: listarchive@realsoftware.com
Received: by 10.220.73.15 with SMTP id o15cs72203vcj;
       Tue, 28 Apr 2009 16:29:57 -0700 (PDT)
Received: by 10.142.125.4 with SMTP id x4mr1551178wfc.75.1240961397398;
       Tue, 28 Apr 2009 16:29:57 -0700 (PDT)
Return-Path: <realbasic-nug-bounces@lists.realsoftware.com>
Received: from advanced107.inmotionhosting.com (advanced107.inmotionhosting.com 
[74.124.194.228])
       by mx.google.com with ESMTP id 22si859439wfg.3.2009.04.28.16.29.56;
       Tue, 28 Apr 2009 16:29:57 -0700 (PDT)
Received-SPF: neutral (google.com: 74.124.194.228 is neither permitted nor 
denied by best guess record for domain of 
realbasic-nug-bounces@lists.realsoftware.com) client-ip=74.124.194.228;
Authentication-Results: mx.google.com; spf=neutral (google.com: 74.124.194.228 
is neither permitted nor denied by best guess record for domain of 
realbasic-nug-bounces@lists.realsoftware.com) 
smtp.mail=realbasic-nug-bounces@lists.realsoftware.com
Received: from localhost ([127.0.0.1] helo=advanced107.inmotionhosting.com)
        by advanced107.inmotionhosting.com with esmtp (Exim 4.69)
        (envelope-from <realbasic-nug-bounces@lists.realsoftware.com>)
        id 1LywjP-0007QM-8C; Tue, 28 Apr 2009 16:28:55 -0700
Received: from boundless.dns-defender.com ([69.65.40.13])
        by advanced107.inmotionhosting.com with esmtps (TLSv1:AES256-SHA:256)
        (Exim 4.69) (envelope-from <fargo@rpgportland.com>)
        id 1LywjM-0007QG-TC for realbasic-nug@lists.realsoftware.com;
        Tue, 28 Apr 2009 16:28:53 -0700
Received: from localhost ([127.0.0.1] helo=rpgportland.com)
        by boundless.dns-defender.com with esmtpa (Exim 4.69)
        (envelope-from <fargo@rpgportland.com>) id 1LywjO-0003gL-JD
        for realbasic-nug@lists.realsoftware.com;
        Tue, 28 Apr 2009 18:28:54 -0500
Received: from 24.20.159.142 ([24.20.159.142])
        (SquirrelMail authenticated user fargo@rpgportland.com)
        by rpgportland.com with HTTP; Tue, 28 Apr 2009 18:28:54 -0500 (CDT)
Message-ID: <61272.24.20.159.142.1240961334.squirrel@rpgportland.com>
In-Reply-To: <49389.71.182.94.210.1240949535.squirrel@rpgportland.com>
References: <63367.24.20.159.142.1240885466.squirrel@rpgportland.com>
        <49F68471.1070007@inspiringapps.com>
        <49389.71.182.94.210.1240949535.squirrel@rpgportland.com>
Date: Tue, 28 Apr 2009 18:28:54 -0500 (CDT)
Subject: Re: RB3DSpace width vs Window width
From: fargo@rpgportland.com
To: "REALbasic NUG" <realbasic-nug@lists.realsoftware.com>
User-Agent: SquirrelMail/1.4.13
MIME-Version: 1.0
X-Priority: 3 (Normal)
Importance: Normal
X-AntiAbuse: This header was added to track abuse,
        please include it with any abuse report
X-AntiAbuse: Primary Hostname - boundless.dns-defender.com
X-AntiAbuse: Original Domain - lists.realsoftware.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - rpgportland.com
X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: realbasic-nug@lists.realsoftware.com
X-Mailman-Version: 2.1.10
Precedence: list
Reply-To: REALbasic NUG <realbasic-nug@lists.realsoftware.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: realbasic-nug-bounces@lists.realsoftware.com
Errors-To: realbasic-nug-bounces@lists.realsoftware.com
X-AntiAbuse: This header was added to track abuse, please include it with any 
abuse report
X-AntiAbuse: Primary Hostname - advanced107.inmotionhosting.com
X-AntiAbuse: Original Domain - realsoftware.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - lists.realsoftware.com

fargo@rpgportland.com wrote:

calculations tend to be based off incorrect information. Specifically
the
window will have returned to its smaller size, in this case 469 wide,
but
the 3d space still reports 1280 at the time of my method call.

Yeah, the Rb3DSpace probably has to be updated before it will realize
that it's been resized.

Anyone know of a good way to get around this lag? I tried running this
loop before my position update method-
  if me.FullScreen then
    me.FullScreen = False
    while myspace.width <> me.width
    wend

Hah, good try, but no, it's not a time lag here; it's an
event-processing thing.  Try myspace.Update.  If that doesn't work, then
you'll have to simply start a single-fire timer whose Action event calls
MoveLabels.  Even a period of 1 would probably suffice, since the point
is just to let the event loop finish doing its work.

Best,
- Joe

--
Joe Strout
Inspiring Applications, Inc.
http://www.InspiringApps.com

Thanks Joe, I'll give that a shot.

And that (the timer) worked brilliantly. I had previously tried passing a
few updates to myspace, but that was goin' noplace.

In any case, I believe at last count I owed you 432 beers, so just add one
more to the tally.

Thanks,
Fargo


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>


<Prev in Thread] Current Thread [Next in Thread>