akitchin

nope, i've got no interest in becoming an author (well, for non-academic literature anyway). it just feels like anyone can start a blog with a mildly clever topic, marginal writing skills, and land a book deal.

is anyone else tired of a catchy/funny blog leading to another goddamn book deal?

this is the scariest thing i've ever read - someone like this, processing CC numbers. gives me the willies.

any chance we can see the revised script? note that there was an ampersand before $previousResult in the cell() definition.

i suppose reading the thread before replying is overrated.

your best bet here is likely to add the $previousResult into the scope just above cell(), and pass it by reference to the function: function cell(&$previousResult, $msg, $sizeCell, $align="left", $cellColorId = NULL){ this will pass the $previousResult variable (see below for where we set it in the new code) by reference, which essentially tells the function to operate on that variable at the scope above the function. for more info, check the php manual for functions. $previousResult = 0; $listPrd = open_line(); $listPrd .= cell($previousResult, "Aviation Products Manufactured / Serviced", "50", "left"); $listPrd .= cell($previousResult, "Estimated Annual Sales", "50", "left"); $listPrd .= close_line(); this code will start the $previousResult variable at 0 before adding all your cells. if you toss it into your do {} block as well, it will reset it to 0 at the start of each row. this is obviously only a local solution for this issue. if you want a longer-term solution that resides within the functions themselves, you may need to rethink the functions and their arguments, but hopefully this gives you some ideas on how to do it.

how are you calling the section of code in the "pinver" case?

if you have variably named columns, you desperately need to revisit your database's design. doing this with the current design will be a major pain. why not set up a table like this: field_name | field_value field1 | 0 field2 | 1 field3 | 1 this would allow you to use: SELECT field_name FROM table WHERE field_value = 1

i love wandering. it sounds like you'll want to use functions similar to nl2br(), which you can use when the data is outputted to the browser (NOT WHEN IT IS FIRST INSERTED INTO THE DATABASE). after looking at the typography class page, it looks like there are a series of substitutions it will make to format the code correctly. most of this is regular expression substitution, but there may be pre-made classes out there for this.

where should cell() be getting $previousResult from? you're not passing it to the function, and it's not globalized (which is a good thing).

i can't count how many times reading the manual about a function solves a thread, and could have done so even before the thread was posted. i hope you've learned a lesson - the PHP manual is your friend.

it's probably because you have TWO inputs named "gen_id" which will no doubt lead to confusion in what value you're actually passing to your query. either change one of the names, or delete one of the inputs. PS: first, you won't end up with any values in those hidden inputs anyway, since you're not passing any of those variables ($date, $IP, $gen_id, etc.) to the pin() function. second, you don't need semicolons at the end of function statements.

first, not using curly braces will not lead to an error. braces are only required when you need to stuff more than one line of code into a conditional statement: if ($stuff) echo 'stuff'; else echo 'not stuff'; works just fine. however, if you need to do more than that, you need braces: if ($stuff) { echo 'stuff'; echo 'MORE stuff!'; } else { echo 'not stuff'; echo 'SRSLY, NOT STUFF'; } maybe i'm just missing something, but 'welcome' isn't a field that's part of your SELECT query...

SELECT name FROM table WHERE certain_field = 1 it might be helpful to browse for a beginner's tutorial on SQL statements, since this is pretty much the first thing you learn.

you know, i actually quite like the simplicity of this design. the button links at the top could do with a bit of sprucing font-wise, and as axeia mentioned, maybe a simpler and faster rollover would be better (what about just an underline?). one thing that is bothering me is the right bar's contents being aligned to the center. it's VERY difficult to read content that is centered like that - it may need some playing with in terms of padding and positioning of the content (it probably looks goofy being purely left-aligned), but i definitely think you need to address that. otherwise, refreshingly simple design and good colours.

this is the line causing you errors: <?php if(!isset($_SESSION['name'])) header('location: register.php'); it's in write.php, and it's directly after you include header.php. header() is triggering the error, and it's because it is being called after including header.php, which outputs HTML to the browser. this much you know. the reason why it may have suddenly changed is that you'll only see this error if $_SESSION['name'] is not set. presumably you've always been accessing this page AFTER logging in, and therefore the session variable is set. however, if you were to try to access it without having logged in first, it would trigger the error. the best way around this is to check whether the user is logged in in header.php, rather than write.php: <?php // might as well start the session no matter what, because without starting the session, no session vars will be set session_start(); // now, if name isn't set, boot them to registration if(!isset($_SESSION['name'])){ header('Location: register.php'); } require_once('Cn/cn.php'); ?> if you use header.php on ALL pages (even the unprotected ones), then you can simply set a variable such as $force_login and check for that at the same time as checking whether the user is logged in: if(isset($force_login) && !isset($_SESSION['name'])){ write.php should then start like this: <?php // tell header.php to force the user to be logged in $force_login = TRUE; // include the header file include("header.php"); ?> there's no reason you should ever have to use header() after browser output - having to do so is generally bad code design, because usually whether or not you need to use of header() can be determined before sending output to the browser.

I thought that I knew how to use TRIM() but I am having issues. can someone help me with the SQL Statement to remove the "%" at the end of all entries in the accountPCT field? you'd be looking at RTRIM(), but that function only removes whitespace from the end of the string. i'd imagine the most effective route is to use REPLACE(): UPDATE table SET column = REPLACE(column, '%', '') once that's done, you can change the column type and it should retain the correct numbers. perhaps backup the column values before change the column type, just in case.

as for finding a host that installs or officially supports it, this isn't necessary. the functionality may be slightly restricted on certain hosts depending on what extensions are or aren't installed along with the PHP installation, but the framework itself is installed simply by unzipping a set of files onto the server (followed by some fiddling to suit your individual environment).

don't forget the "click here for your prize" portion - always the most important part of the scam.

it's a quick query to go through and chop the percent symbol off of each field in the database, followed by converting the column type once you've done that.

1. have you tried to run that query? if so, you should be able to tell us whether or not it works. 2. in the case that it doesn't, you'll need to run the comparison against the integer portion of the column's value. trim the last character from the field's value, and convert to integers. functions for this can be found in the MySQL manual, OR: 3. do it right - simply store the success percentages as numbers. to add a percentage sign when outputting, simply append it manually at the time of echo. EDIT: whoops, beaten to the punch. i still think #3 is the best solution though - change the column type to match the data it should be holding.

some policies give time in-lieu / banked hours rather than actual overtime pay, and this actually seems to be more prevalent in my area with salaried employees. i agree though, it should not be expected. as Daniel says, consistent reliance on overtime is poor management. it's one thing to be under the gun because of unexpected circumstances on a project (someone forgets a backup, etc.), but it's entirely another to plan the project's progression on overtime hours. i'm on salary with my company (i'm not a programmer by day, i'm a chemist) and basically work under the premise that 12 hours is just a long day, and weekends when you're on site at a facility are part and parcel of the job. at best, we'll get in-lieu days for the weekends if our bosses are okay with it. that's what you get when the office people complain that field guys get too many days off. fucking office politics.

i'm pretty sure we should make a flashing banner ad that will only show to the person who posts the millionth message that says "1,000,000th POST! CLICK HERE TO CLAIM YOUR PRIZE NOW!!!!!!!!!"

my apologies, the issue is simpler than i thought. when you're going through each tomBassOpt, use the key for each one to access the matching tomBassOptem. assuming i've understood you correctly: foreach ($_POST['tomBassOpt'] AS $key => $this_tomBassOpt) { // this $row[1] value will be in $this_tomBassOpt (just as in $tomBassOpt in your foreach loop) // to access the corresponding $row[3] value, simply use: $this_tomBassOptem = $_POST['tomBassOptem'][$key]; } since they'll have matching keys (given how you're echoing them into the previous page), all you need to do is grab the key from the tomBassOpt array item, and access the value using that same key in tomBassOptem.

at first glance, i would presume that caching thumbnails would actually speed up your loading in the accidental case that one folder is set to thumbnail display. you're probably more likely to find stuff on google for this than here. perhaps you need to split them up through even more subfolders.