• Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.

    If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.

    - The Lone Wolf Development Team

XML Transformation Script (PowerShell)

tmilktoast said:
Regarding those Edge of the Empire fonts, I imagine none of you are seeing them in your browser because you probably don't have them installed on your PC.

EightBitz, do you still want me to send you those things you asked for, or were you just going to work on Parody's suggestions?
Click to expand...

Hey, here's something you might find interesting. Remember how there are two types of bulleted lists? One of them isn't actually formatted as a bulleted list. It just throws in a wingdings bullet followed by text.

*Shakes finger at Rob*
 
CSS question for Parody or anyone who's willing to answer. Regarding the following divisions, is there, generally speaking, a preferred order they should be listed in the CSS file, or does it not matter?

.snippet TABLE {}
.snippet TABLE TR {}
.snippet TABLE TR TD {}
.snippet TABLE TR TD P {}
 
Practically: the order doesn't matter for what you're doing here. I generally do the same thing as your example for those sorts of selectors.

Technically: there's an order of precedence and specificity that determines what order CSS rules are applied to matching elements; rules with higher precedence and/or more specificity override earlier ones. Order of appearance in an external CSS file only matters if two selectors have identical precedence and specificity.
 
Last edited:
Parody said:
Practically: the order doesn't matter for what you're doing here. I generally do the same thing as your example for those sorts of selectors.

Technically: there's an order of precedence and specificity that determines what order CSS rules are applied to matching elements; rules with higher precedence and/or more specificity override earlier ones. Order of appearance in an external CSS file only matters if two selectors have identical precedence and specificity.
Click to expand...

I thought that in that order of precedence, inline formatting always took precedence. But that doesn't seem to be the case. With tmilktoast's output, it has the following line (just including the relevant portion):

Code: 
<td class="RWSnippet" style="background-color:#8B0000;...

That's kind of a rusty, reddish color. In my CSS file, I have the following elements (again, just including the relevant portions):

Code: 
.snippet {--main-background-color:white;}
.snippet P {background-color:var(--main-background-color);}
.snippet TABLE {background-color:var(--main-background-color);}
.snippet TABLE TR {background-color:var(--main-background-color);}
.snippet TABLE TR TD {background-color:var(--main-background-color);}
.snippet TABLE TR TD P {background-color:var(--main-background-color);}

When I opened the html file, the background for the text in the table was white. Working my way up from TABLE TR TD P, I commented out each background-color in turn, and when I commented out the one for .snippet P, I saw the proper color in the table.

In the TABLE TR TD P section, I had him change the background-color to transparent, and that worked.

So that was unexpected ... to me anyway. Like I said, I'm still learning. :-)
 
Was the it rendered white or was the code fore the element color white? If it was just rendered white that could be a browser thing. Different browsers handle CSS differently.
 
There's a <p> inside of an element with "snippet" as one of its classes, which matches your ".snippet p" selector. It doesn't matter how deep the containment hierarchy goes:
Code: 
<div class="snippet">
  <p>This matches.</p>
  <div class="whatever">
    <p>As does this.</p>
    <table><tr><td><p>And this too.</p></td></tr></table>
  </div>
</div>
<p>But not this.</p>

That particular <p> should also match ".snippet table tr td p". ".snippet table tr td p" is more specific than ".snippet p", so ".snippet p" should be applied first, then ".snippet table tr td p". The inline style would have precedence if it was on the <p>, but it's not; it's on a <td> that happens to contain a <p>, and both of the selectors that match the <p> also set the background-color.

Let's take a step back. Your goal is to not have a background-color for the text in the cell and let the cell's background-color show through. The term for that for background-colors is "transparent". It's also the default, which is usually specified in CSS with "initial". Something like this might work for you:

Code: 
.snippet {
  background-color: white;
}

.snippet p { /* default formatting for regular paragraphs */ }

.snippet table { /* default table formatting */ }

.snippet table p {
  /* reset the background color */
  background-color: transparent;
}

This doesn't do much by itself, but if you do specify a different background-color for a <table> or <tr> or <td> or whatever and they happen to contain <p>s, then hopefully this will make it do what you actually want.

Note that this is only needed because something is overriding the default. If your ".snippet p" selector doesn't include a background-color, then you don't need to override it for tables containing <p>s. The less you specify, the better. :)

FWIW, if you want a selector that means "only <p>s directly contained inside an element with the 'snippet' class", you could try try ".snippet + p". Also you don't need to use <p>s inside of <td>s or <th>s, so if there's only one <p> in a cell or header you could strip it.
 
Last edited:
Parody said:
There's a <p> inside of an element with "snippet" as one of its classes, which matches your ".snippet p" selector. It doesn't matter how deep the containment hierarchy goes:
Code: 
<div class="snippet">
  <p>This matches.</p>
  <div class="whatever">
    <p>As does this.</p>
    <table><tr><td><p>And this too.</p></td></tr></table>
  </div>
</div>
<p>But not this.</p>

That particular <p> should also match ".snippet table tr td p". ".snippet table tr td p" is more specific than ".snippet p", so ".snippet p" should be applied first, then ".snippet table tr td p". The inline style would have precedence if it was on the <p>, but it's not; it's on a <td> that happens to contain a <p>, and both of the selectors that match the <p> also set the background-color.

Let's take a step back. Your goal is to not have a background-color for the text in the cell and let the cell's background-color show through. The term for that for background-colors is "transparent". It's also the default, which is usually specified in CSS with "initial". Something like this might work for you:

Code: 
.snippet {
  background-color: white;
}

.snippet p { /* default formatting for regular paragraphs */ }

.snippet table { /* default table formatting */ }

.snippet table p {
  /* reset the background color */
  background-color: transparent;
}

This doesn't do much by itself, but if you do specify a different background-color for a <table> or <tr> or <td> or whatever and they happen to contain <p>s, then hopefully this will make it do what you actually want.

Note that this is only needed because something is overriding the default. If your ".snippet p" selector doesn't include a background-color, then you don't need to override it for tables containing <p>s. The less you specify, the better. :)

FWIW, if you want a selector that means "only <p>s directly contained inside an element with the 'snippet' class", you could try try ".snippet + p". Also you don't need to use <p>s inside of <td>s or <th>s, so if there's only one <p> in a cell or header you could strip it.
Click to expand...

Yep, that's exactly how I fixed it for him. Then he has to go and ask if it's possible to extract the images and such instead of leaving them embedded.

So guess what I've been working on... That's the thanks I get for helping him out. Jerk. ;-p
 
Yeah, that's a little bit more of a pain. I've been working on a tool to unpack MHT files (think "web site saved as an email with attachments") which has to deal with the same thing.
 
Parody said:
Yeah, that's a little bit more of a pain. I've been working on a tool to unpack MHT files (think "web site saved as an email with attachments") which has to deal with the same thing.
Click to expand...

With PowerShell, the deed itself is just two lines of script.
Code: 
$bytes = [Convert]::FromBase64String($Contents)
[IO.File]::WriteAllBytes($FilePath,$bytes)

The painful part is integrating it with everything around it.
 
Well, yeah. Also you have to know you don't mind spending the RAM for it. (RW's 30MB limit helps there.)

I keep wanting to make a more fully fleshed out tool instead of just a quick-and-dirty thing that does what I'm actually trying to accomplish. :)
 
Last edited:
Parody said:
Well, yeah. Also you have to know you don't mind spending the RAM for it. (RW's 30MB limit helps there.)

I keep wanting to make a more fully fleshed out tool instead of just a quick-and-dirty thing that does what I'm actually trying to accomplish. :)
Click to expand...

Meh, these days everyone as an extra jigawatt or two of RAM.
 
EightBitz said:
Yep, that's exactly how I fixed it for him. Then he has to go and ask if it's possible to extract the images and such instead of leaving them embedded.

So guess what I've been working on... That's the thanks I get for helping him out. Jerk. ;-p
Click to expand...

You're very welcome.

I mean, thank you. :D
 
Anyone else seeing this go non-responsive when it runs the script? It works don't get me wrong. And it looks great. But the GUI freezes up and I need to close it out manually.
 
daplunk said:
Anyone else seeing this go non-responsive when it runs the script? It works don't get me wrong. And it looks great. But the GUI freezes up and I need to close it out manually.
Click to expand...

The GUI disables itself while the script is running. When the script completes, the GUI reactivates itself. This happens to indicate when the script starts and when it completes, so you're not left wondering. There are probably better ways to manage this, and I can work on that later, but for now, that's how it works.

If the GUI remains greyed out and non-responsive, there's an issue with the script, or at least with that particular run of it. I'd need more details, of course, to determine exactly what's happening here.

Maybe something is getting caught in a loop, or maybe something is happening to prevent the form from reactivating itself. Maybe the script is taking longer to run than you realize. Various possibilities exist.
 
In the next release, I'll just disable the run button instead. That will still offer an indicator that the script is active without disabling the whole form.
 
I did the same export twice and it appears to have completed but just stays disabled. Ill try it with a different file and see if the export is the cause.
 
I just updated the GUI. I got the "Load" button working, and I added a "Save Defaults" button. The Load button will only work properly with scripts saved by the GUI.

I figure these two changes will make life immensely easier for anyone using the GUI.

EDIT: Click the link in the first post. I didn't change version numbers or anything. This one's just a quickie with no changes to the primary script.
 
You must log in or register to reply here.
Back
Top