What's a decent XML editor specifically for editing/viewing SMS messages copied from Android to Windows?

[Arlen Holder]

Q1: What's a decent XML editor specifically for editing/viewing SMS messages
archived from Android to Windows (in the XML text archive format).
<https://i.postimg.cc/L5WsCrNq/xml01.jpg>
Q2: Why do these SMS backup programs use XML anyway?

Other than while graphically layout out Hello-World simple apps in
Android Studio freeware, I've never had to deal with XML on Windows.'
<https://groups.google.com/d/msg/comp.mobile.android/aW64zYeBtF0/1b5h3r3PBAAJ>

I need help figuring out _what_ is in a bunch of newly created XML files.
o What free editor/viewer would you recommend for my generic needs below?

What's the problem set?
1. Someone asked on comp.mobile.android how to copy SMS/MMS from Android to Windows.
<https://groups.google.com/forum/#!topic/comp.mobile.android/d0Y8CqDTaog>
<https://groups.google.com/forum/#!topic/comp.mobile.android/xwX8S7XW-p0>
2. I tested these free apps, both of which created XML files.
o *SMS Backup & Restore*, by SyncTech Pty Ltd
<https://play.google.com/store/apps/details?id=com.riteshsahu.SMSBackupRestore>
"backs up and restores your phone's SMS and MMS messages and call logs."
o *Super Backup & Restore*, by MobileIdea Studio
<https://play.google.com/store/apps/details?id=com.idea.backup.smscontacts>
"You can backup applications, contacts, text messages, call history,
bookmarks, calendars to your SD card, Gmail, or Google Drive"
(some functions require root)
3. I copied the XML results to Windows.
\sms_backup_and_restore\calls-20200421011403.xml
\sms_backup_and_restore\sms-20200421011403.xml
\super_backup_and_restore\sms\sms_20200421012301.xml
\super_backup_and_restore\logs\calllogs_20200421012328.xml

Now what?
o How can we best view/edit these SMS XML files on Windows?

Obvious I doubleclicked on them, which brought up the XML tagged results in
Windows Internet Explorer (of all things). Obviously I googled and installed
what seems to be the canonical XML freeware editor, from Microsoft...
o *XML Notepad 2007*
<https://www.microsoft.com/en-us/download/details.aspx?id=7973>
Name: XmlNotepad.msi
Size: 1917440 bytes (1872 KiB)
SHA256: 7420A936C167ACAFDC9421181B579FE8ECFF6D43937EDCEF93E2A1321F8141FF

Unfortunately, it required more stuff from Microsoft...
o .NET Framework 3.5
<https://dotnet.microsoft.com/download/dotnet-framework/net35-sp1>
Name: dotnetfx35.exe
Size: 242743296 bytes (231 MiB)
SHA256: 0582515BDE321E072F8673E829E175ED2E7A53E803127C50253AF76528E66BC1
Which, when clicked, _still_ tried to download more stuff from the net.

Finally, when I was able to read the XML file, the question may have
been partially mooted (mootified?) simply because the contents the backup
contained are rather uninspiring.

Nonetheless, the question arises as to what's a good free Windows XML editor?
And, why do these freeware SMS backup programs choose XML format anyway?
<https://i.postimg.cc/L5WsCrNq/xml01.jpg>
--
Together we can accomplish far more than any one of us can alone.

[Paul]

OK, so I seen in the question a mention of "SMS Backup & Restore",
which implies someone wants to make a storage format for their works,
one which can be parsed later using one of the available parsers.
You can prepare "databases" if you want, as XML has name:value pairs.
If they instead used a database format, it likely wouldn't be
crossplatform, and the people on some platform, would feel "ignored".

It doesn't necessarily suggest that people go around editing
the content of the files. If it's for backup and restore.

Perhaps a customer would like a "conversion" process, for converting
the payload section of the backup, into some other format. That
can be done with text processing languages and/or scripts. PERL
being an example.

If the bog-standard XML files need to be "pretty", a web site
like jsbeautifier.org loads some javascript in the browser
which does *local* processing of presented pasted materials.
The materials are not sent to the website for server processing.
Just the browser does the transformation. This would add things
like indentation to an improperly indented XML. If the damage
is severe enough (maybe no line endings), the javascript isn't
clever enough to resolve all issues of that type. But it can
improve the appearance, if you don't like what you see.

If I need to edit an XML for VirtualBox or VPC2007 or the like,
I just use Notepad for the couple lines needing modification.

Paul

[GS]

There are SMS converters out there that will reformat the messages to whatever
host email app is going to view (or import) them. Google is your friend here!

Otherwise, XML parsing gets complicated depending on what results you want and
so forth. Thus, an SMS conversion utility is the way to go. Chances are, your
Windows email app can import directly from your device!

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

[Arlen Holder]

In response to what Paul <nos...@needed.invalid> wrote :

> OK, so I seen in the question a mention of "SMS Backup & Restore",
> which implies someone wants to make a storage format for their works,
> one which can be parsed later using one of the available parsers.

Hi Paul,

Thanks for explaining why they use XML format for SMS/MMS backup.
o *My hope is to see images from MMS messages, in the Windows XML editor.*

Regarding why these MMS/SMS backup programs chose XML as their storage
format, I think you're almost certainly correct - as it's a standard
non-proprietary cross-platform 'storage format' that can be easily parsed.

Bear in mind what I was _really_ after, were the MMS pictures, since the
photos sent to me by my kids and grandkids and relatives are the only
things I really care about in SMS/MMS archives.

To be clear, I _already_ autoarchive those photos outside of the MMS
message in which it was contained (the PulseSMS freeware app has a setting
that does just that) - but still - if you're gonna archive MMS/SMS
messages, then I was hoping the _photos_ were inside that XML archive.

When I said the results in Microsoft XML Notepad 2007 were "uninspiring",
what I was _hoping_ to see inside the XML archives in the Windows XML
editor, were those MMS photos, but I didn't see them (I was expecting a
mime-encoded inclusion, for example).

I _still_ don't know if those MMS photos are inside the archive or not, but
if I read the blurb on the tools, they "claim" to archive MMS messages (but
they don't specifically mention the photos).

<https://play.google.com/store/apps/details?id=com.riteshsahu.SMSBackupRestore>
"SMS Backup & Restore is a simple Android app that backs up and
restores your phone's SMS and *MMS* messages and call logs."
"Backup SMS (text) messages, *MMS* and call logs in XML format."

<https://play.google.com/store/apps/details?id=com.idea.backup.smscontacts>
"READ YOUR TEXT MESSAGES (SMS OR *MMS*)/EDIT YOUR TEXT MESSAGES
(SMS OR *MMS*)
These permissions are used to backup & restore your SMS"

My main reason for wanting the XML editor was to "see" those MMS images!

In short, I was "hoping" the Windows XML editor would display the MMS
images, but, so far, I don't know if MMS images are even there or not.
--
When testing software for the first time, basic confusion often results.

[Paul]

If an image was present, it must take space. Storage space.
Have a look around for something suspiciously big looking
inside the set of files.

If a provider somehow provides a cloud service, and only
a URL inside the XML files points to a file stored elsewhere,
then you have your answer as to where your picture went.
It could be an Evil Cloud got it.

Paul

[Arlen Holder]

In response to what Paul <nos...@needed.invalid> wrote :

> If an image was present, it must take space. Storage space.
> Have a look around for something suspiciously big looking
> inside the set of files.

Hi Paul,
You're maybe on to something with respect to size...

The interesting thing is that both apps were used to back up the SMS/MMS
but one app backed up ten times as many SMS "bits" as did the other app:
o SMS Backup & Restore SMS log = 384MB
o Super Backup SMS log = 335KB
<https://i.postimg.cc/dtDwkn3V/xml02.jpg>

That same app backed up only twice as many bits of the call log:
o SMS Backup & Restore call log = 64KB
o Super Backup call log = 23KB
<https://i.postimg.cc/MpdL7JLk/xml03.jpg>

> If a provider somehow provides a cloud service, and only
> a URL inside the XML files points to a file stored elsewhere,
> then you have your answer as to where your picture went.
> It could be an Evil Cloud got it.

If they're both supposedly of the same SMS/MMS texts, there's a ten-fold
size difference, which implies the pictures might be the difference.

Maybe there's a reference link to the MMS pictures; or maybe one is just
more efficient at their storage format than the other; or, maybe one is
backing up more stuff than is the other... or ...

This is kind of why I wanted a good solid XML Editor/Viewer on Windows.
--
The first time we look at such things, the results are confusing.

[Paul]

If you have a 384MB file of unknown type, you can pop it into HxD for a look.

https://mh-nexus.de/en/hxd/

There's all sorts of things they could do to it to obfuscate.

Using the hex editor first, is just to see if it's binary before
throwing it into a text editor.

Paul

[Arlen Holder]

In response to what Paul <nos...@needed.invalid> wrote :

> If you have a 384MB file of unknown type, you can pop it into HxD for a look.
>
> https://mh-nexus.de/en/hxd/

Hi Paul,

Thanks for the hex editor suggestion.

I popped the XML file into hxd which shows pretty clearly there is ASCII
and binary, where the binary is surrounded by <parts>xxx</parts> tags in
some instances.
<https://i.postimg.cc/26LJtdmC/xml04.jpg>

It "could" be text plus images, where nothing I saw didn't indicate that to
be the case, but of course, I'm reading hex code to determine that.
<https://i.postimg.cc/kXLV3qx9/xml05.jpg>

I was hoping a good XML editor would parse out the photos.
o Maybe I just need a _better_ XML editor for Windows?

However, one slightly indirect option to figure out if the archive contains
images is to delete all the SMS texts on the phone and then try to restore
them, which would be a pain, but it would definitively answer the question
of whether the backed up XML archives contain MMS images.

But that's why I asked for an XML editor to read the XML archive file!
o I'm assuming a good XML editor would be able to parse the XML file.
--
There are so many ways to back up Android to Windows that it's confusing.

[Paul]

The stuff before the /parts is BASE64 or ASCII85.

Converting it from the textual encoding evident in your picture,
to its original binary form, that wouldn't work well in a text editor.

Should an "editor" recognize every multimedia type in existence,
like the 500+ things the Linux "file" command recognizes ? Once the
ASCII85 is converted back to binary format, now we'd have to recognize
what it was by signature.

I'm not even sure that XML is intended for this kind of encapsulation.
Normally the XML files I've seen, they contain configuration information,
single lines with filenames or the like. To pour binary into the file
in a less efficient BASE64 or ASCII85 format, seems a bit on the silly side.
Maybe it succeeds at making the result "portable".

An editor that in any way thought it was dealing with text, would
suffer from the "Notepad problem". Where the average text editor
designer, cannot seem to handle memory management worth a damn,
and there's always an artificially low limit to the file size.
Currently on the best of days now, Notepad is still less than
around 1GB or so. At least Notepad (on Windows 10), doesn't
suck like it used to. You can do find and replace now, and it
actually works.

Paul

[Arlen Holder]

In response to what Paul <nos...@needed.invalid> wrote :

> The stuff before the /parts is BASE64 or ASCII85.

Hi Paul,
<https://i.postimg.cc/wj0n4P9D/xml06.jpg>

*PLAN A:*
Thanks for your helpful advice on the fact I'd need a pretty high end XML
editor that would be able to figure out it's images that are encoded in the
XML backup file.

I think the evidence points to the fact that it's highly likely pictures
from MMS _are_ encoded in that XML file, where PLAN A was that I was hoping
to find an XML Editor on Windows that would prove that to be the case.

> Converting it from the textual encoding evident in your picture,
> to its original binary form, that wouldn't work well in a text editor.

*PLAN B:*
I decided on PLAN B, which was restore the XML file but use a _different_
SMS app to restore it to so I could see if the pictures were also restored.
<https://i.postimg.cc/wj0n4P9D/xml06.jpg>

The restore procedure is interestingly unexpected:
1. On Android, I pressed the RESTORE button in "SMS Backup & Restore"
2. It asked to be set to the default SMS app temporarily.
3. It gave the option to "Restore pictures, media, & group messages (MMS)".
4. Once it finished, it said to choose the "real" SMS app as the default.
5. I installed a different (new) SMS app to make the default SMS app.
6. Once I set it to the default SMS app, the photos showed up inside it.

In summary, my PLAN A was to try to "edit" or "view" the XML backup of my
SMS/MMS texts on Windows (where that XML backup almost certainly contains
binary "images" that were sent to me).

Once I gave up on finding a good XML editor that will show the embedded
images, I simply restored the backup, where that restoration process
"appears" to have brought back the images that were in my MMS messages.

There's a bit of a doubt because I never deleted the images from the third
SMS app, but I'm gonna run with this theory as I was only testing the
software to help others who asked for a good freeware Android SMS/MMS
backup to Windows.

Given the resulting XML file is ten times larger with one backup program
over the other, my recommendation, moving forward, is:

o *SMS Backup & Restore*, by SyncTech Pty Ltd
<https://play.google.com/store/apps/details?id=com.riteshsahu.SMSBackupRestore>
"backs up and restores your phone's SMS and MMS messages and call logs."

Thanks for your kind help and advice, where I think I'll just give up on
the XML editor unless someone suggests one that will work with embedded
images in the XML file.
--
The beauty of helping others on Usenet is we all learn more together.

[Mayayana]

"Paul" <nos...@needed.invalid> wrote

| I'm not even sure that XML is intended for this kind of encapsulation.

It won't matter. XML is bloated, overused crap with one
advantage: You can mark the beginning and end of data
uniquely. It's really just customizable HTML. (Thus the X,
for extensible.) Like JSON, it's a pain in the neck and gross
overkill in most cases. Both are more fashion than tool.

But the format does make order extensible. So there's no
reason it can't hold Base64. HTML and MIME both store it
just fine. Personally I've never seen a text message package
so I have no idea whether it *does* hold Base64.

[GS]

Base64 IS plain text. The problem with using it in email is, depending on how
the body text is converted, character case may be lost where all UCase becomes
LCase. Best to convert B64 to Hex for email use, IMO!

[Mayayana]

"GS" <g...@v.invalid> wrote

| > But the format does make order extensible. So there's no
| > reason it can't hold Base64. HTML and MIME both store it
| > just fine. Personally I've never seen a text message package
| > so I have no idea whether it *does* hold Base64.
|
| Base64 IS plain text. The problem with using it in email is, depending on
how
| the body text is converted, character case may be lost where all UCase
becomes
| LCase. Best to convert B64 to Hex for email use, IMO!
|

I meant I've never seen the actual content of a text
message. SMS. Email and HTML and Base64 are plain
text, yes. I only meant that their formatting allows Base64
data to be stored easily. Multipart MIME format and "data
uri" formatting in HTML make it simple with no risk of
mixup. It can also be simple in XML:
<Data64> ....any length text here...</Data64>

In other words, they all have protocols for storing Base64
data that can be identified as Base64.

I don't know what you mean about converting Base64
to hex. Binary? The whole point of Base64 is that HTML
and email can't have binary data. If the Base64
gets ucased then there's something wrong with the
email structure.

[GS]

I've had instances where writing B64 email body text with VB displays correctly
in the new msg window, but arrives w/all UCase converted to LCase. My solution
to preserve the original B64 is to convert each character to its Hex equivalent
as follows:

Garry
R2Fycnk=
52324679636E6B3D

..which all are plain text strings. Otherwise the B64 string arrives as
"r2fycnk="! The reason for the need is because the B64 string is the result of
encrypting a license profile and outputting the result (byte data) in B64 so it
behaves like a string when being processed as a plain text file.

[Mayayana]

"GS" <g...@v.invalid> wrote

| Garry
| R2Fycnk=
| 52324679636E6B3D
|
| ..which all are plain text strings. Otherwise the B64 string arrives as
| "r2fycnk="! The reason for the need is because the B64 string is the
result of
| encrypting a license profile and outputting the result (byte data) in B64
so it
| behaves like a string when being processed as a plain text file.
|

I see what you mean. The problem there is that you're
sending it in the plain text section. If you want it treated
as Base64 it needs to be demarcated. Though it still shouldn't
lcase. Maybe you're using spellcheck? Your method is probably
best for a short string. If you want to actually send base64 you
need to use multi-part format and do it like so:

--UNIQUE_BOUNDARY_STRING_HERE
Content-Type: image/jpeg;
name="pic.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="pic.jpg"

Then you put the base64, followed by another
boundary marker. Otherwise there's no way for
the client to know you intend it to be interpreted
as base64.

You can see samples if you look at an email with
attachments.

[GS]

Actually, it goes as body text in a new msg via the user's default mail app
using ShellExecute's mailto: arg. This puts the 'Send' action as user choice
because I refuse to send anything not user authorized.

[Mayayana]

"GS" <g...@v.invalid> wrote

| Actually, it goes as body text in a new msg via the user's default mail
app
| using ShellExecute's mailto: arg. This puts the 'Send' action as user
choice
| because I refuse to send anything not user authorized.
|

Yes, I understand. That's the problem. And you're
at the mercy of their spellcheck. And most people use
spellcheck. So your spelled-out hex codes method
makes more sense.

But that's not a shortcoming of email. If you look at
the email code you'll see that the mime type of the body
section is clearly marked as plain text and/or html. You
can't just say, "Don't touch this sentence. It's base64." You have
to put base64 in its own section. (Some body sections are
actually entirely base64. I don't know why. It's not secure
and it increases the size by 1/3. But maybe it helps to foil
things like NSA sniffers looking for keywords. In any case,
even a base64-encoded body wouldn't help you. It would
be encoding *after* the spellchecker has already altered
your key.)

It's an interesting problem you had, though. I used to
send activation keys via email and it never occured to
me that they could become corrupted. But I don't use spellcheck.
And I've never designed a system where I use someone
else's email to send something to me. I'm surprised it doesn't
mess with your hex. "CBC231... Did you mean 'cabbage'?"

That's what I meant in saying email and HTML can handle
base64. They have a way to include it, but of course that
way has to lead the client to accurately interpret which part
is base64. It has to be systematic. It's actually becoming
more common in HTML. Email and HTML are both systematic
and both can accomodate base64 in various ways.

The HTML way is
such a handy idea that I wrote drag-drop VBScripts to
convert an image and put it on the Clipboard. I use it
to make webpages with images built in. For instance, recently
I was looking up a houseplant and wanted to save a picture with
info about the species. Inline base64 made that very easy,
putting it all into a single HTML file.
Here's an example:

<HTML><HEAD></HEAD><BODY>
This is a picture<BR>
<IMG WIDTH=40 HEIGHT=82
SRC="data:image/gif;base64,R0lGODlhKABSAPcAAAAAxggIxhAQxiEYxikpxjExzkI5zkpKzlJSzmNa1mtr1nNz1oR71oyM1pSU3qWc3q2l3rW13sa958bGxs7G587OztbW1tbW597e3ufe5+fn5+/n5+/v7/f39///7////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////ywAAAAAKABSAAAI/gABCBxIsKDBgwgTKlzIsKHDhxAjSpxIsaLDDR4yasy4oePGjR4/ckwosqTJkx5IisR4kqVJjCo5onRZkqZKmjQ94NSIcWfMmiA/7tS54ebMlzpFGl15lCnJnDmFHv0ZNGrSqzI1Lu2JNatVmwiZumT5teRSmVCPskxoFWXLtWGzAk079CzZoHKxhjyLlmNaqTqpIkXaE+7BrjvJRr0bOC5PvB8LOo07FrFfyY8bH9ZLVCQEg5MPVoYME/RKtnM3On78VK5HwwA+DzQpGGdRghEIMs7IlyaBgQM8SCDIcy/CkF1T6t6Qe/Zo1K41A9A4fLbZ1TmJs2wuMDNvykoH/mqQyR3AbuWidxNk8LF8Z5k3XRK0INJ91Jg9HyzP6j6p/LAu/ebcex70B9Jtm2FkAXGQ9VcZfgyaZCBRpSUYoYQX/ifadwAI0BFXWJV3HmoIVnRVaxZ1p5VjKU63YoLFtcUcgx/2xFZbGFp3YHyJFVdghCC29thoGol4HYxuFXmhatglV5mDkQEoFYjk0RjlhisV9lF1KvrFoWkEekcdkExuNiVkg32JGWmA5XUlmB+ymVqZBv2VZJvo1TlUS0C9CCaaYrol5JBi2ulnQa8dCBiOSVGlWKBJ4ndnXshJt2Z0dypWIWh/lcWoYEJVGmZQoHZGV3InOqalWF66meelHKj22Raoojr51aA11Qpoi7z26uuvwAYr7LDDBgQAOw=="
/>

</BODY></HTML>

If you save that as HTML you'll get a webpage with a small
picture of a "4". The only limitation is that IE was late in implementing
it. Older IE versions can only handle an image up to something
like 32 KB. Anything bigger and IE will clip it.

[GS]

I initially tried sending the license.dat file as an attachment but couldn't
get that to work in my current method. Works fine using CDO but not wanting to
use my gmail credentials because they block anything not coming from my IP
address. I suppose I could use my website mail account where the email is being
sent to, or create a new mailbox just for this purpose (built into the
registration process), then inform users their registration has been sent. I'll
play with it some since I'm keen to test drive the CDO code Obiwan posted in
the VB forum recently.

[Mayayana]

"GS" <g...@v.invalid> wrote

|not wanting to
| use my gmail credentials because they block anything not coming from my IP
| address.

Really? A police state run by spyware. That's a new one.

| I suppose I could use my website mail account where the email is being
| sent to, or create a new mailbox just for this purpose (built into the
| registration process), then inform users their registration has been sent.
I'll
| play with it some since I'm keen to test drive the CDO code Obiwan posted
in
| the VB forum recently.
|

If you're interested in doing it yourself you can also
see here:

https://www.jsware.net/jsware/vbcode.php5#mail3

I wrote this years ago and have occasionally updated it.
Completely free of dependency. It uses straight winsock to
talk to the smtp server. VBSendMail was similar but
required the winsock control.

CDO might be OK. I'm not sure how many systems it's
on. As I recall there was cdo, cdosys, and maybe something
else. I don't remember details now but you should check
that out. Also, as Obiwan said, it could be disabled in
some cases.

My code still requires an email address and has one notable
limitation: no encryption. My own email server allows
unencrypted email, so I could put this code in my program
and send emails from client machines if I wanted to. (Of
course, if they're like me they don't allow just any old
program to go online, but that's another issue. :)

Another possibility might be a URL. Something like
www.garryssite.com/autoregister.php?ID=2341654&key=BC13ED

But you'd need to set up the PHP serverside to deal
with that. You could probably find enough code online
to do it, but I'm not sure. You'd need to process the
PHP parameters and then have some method to store
the data in a log or database. Or for a rally simple
version, you could download your server logs daily,
search for autoregister GETS, and process the data
locally.

[Arlen Holder]

In response to what GS <g...@v.invalid> wrote :

> I'm keen to test drive the CDO code Obiwan posted in
> the VB forum recently.

As an aside, Garry is apparently referring to these searchable archives:
o <http://tinyurl.com/comp-lang-basic-visual-misc>
o <http://tinyurl.com/microsoft-public-vb-general-di>
(there is a 30-character limit)
or...
o <http://comp.lang.basic.visual.misc.narkive.com>
o <http://microsoft.public.vb.general.discussion.narkive.com>
--
Every post to Usenet should strive to add further value to the ng.

[GS]

> If you're interested in doing it yourself you can also
> see here:
>
> https://www.jsware.net/jsware/vbcode.php5#mail3
>
> I wrote this years ago and have occasionally updated it.
> Completely free of dependency. It uses straight winsock to
> talk to the smtp server. VBSendMail was similar but
> required the winsock control.

I will have a look at this as well. Though, none of my non-corporate users have
IT restrictions nor do any IT tasks themselves. Corporate clients use site
licenses and so why I do it via the user default email.

No need to fix since it "ain't broken", but I'm all for learning other ways; -
thanks for your generous input!

[GS]

> In response to what GS <g...@v.invalid> wrote :
>
>> I'm keen to test drive the CDO code Obiwan posted in the VB forum
>> recently.
>
> As an aside, Garry is apparently referring to these searchable archives:

> o <http://tinyurl.com/microsoft-public-vb-general-di>

Yes, Mayayana was involved in the discussion. Sorry my post took your
time/effort, but I appreciate it none the less!