Replying to sp:

... any string that is only alphanumerics would be a control id, since that would not be a valid selector.

Any HTML tag name is alphanumeric and is a valid jQuery selector, isn't it? So "alphanumerics only" doesn't necessarily mean QCubed control. I understand, this is unlikely to cause problems (since no one should use a selector with a tag name alone as a handle for QDraggable), but is there a way to be more "correct" here? Why do we really need to "fix" the value assigned to the property? Shouldn't the user worry about passing the proper selector, prefixing it with '#' if necessary?
If we're trying to have an easier to use version for developers, perhaps we could have another property called HandleControlId or something, which will prefix the passed in control id with '#'.

Currently the QApplication::IsRemoteAdminSession() function can only handle a list of simple IP numbers configured in ALLOW_REMOTE_ADMIN. Many people have dynamic IP's and their IP's change within a range. The attached patch adds support for IP number ranges. It handles 3 formats of range specifications like "10.1.1.1 - 10.1.1.255", "10.1.1.1/24" or "10.1.1.1/255.255.255.0".

(diff)

Removes the escaped quotes and makes them appear normal.

I am using PG with my app and when dealing with the varchar fields, I am getting the escaped strings as the output. This patch removes the behavior imedeately. However I think a little more inspection is required for the problem.

use FetchCellValueFormatted? to make sure object's are formatted correctly

To demonstrate add the following tin jq_example.php

$this->Accordion->Active = false; $this->Accordion->Collapsible = true;

then expand and collapse one of the accordion panels.
The fix is to allow boolean values in the _SelectedIndex setter, since jQuery accordion's Active property accepts boolean values.

Added my name (Vaibhav) in the list.

(diff)

I ended up with the following code in QEmailServer

public static function WrapStringInEncodedWord($strContent, $strWordPrefix, $strWordSuffix){ //encoded word atoms seperated by space return sprintf(' %s%s%s', $strWordPrefix, $strContent, $strWordSuffix); } public static function GetEncodedWordChunks($strQuotedPrintable, $strEncodingType){ $strWordPrefix = sprintf("=?%s?Q?", $strEncodingType); $strWordSuffix = "?="; $intChunksize = 75 - (strlen($strWordPrefix) + strlen($strWordSuffix)); return preg_replace( '/(.{1,'.$intChunksize.'})/ue', "QEmailServer::WrapStringInEncodedWord( '\\1', '".$strWordPrefix."', '".$strWordSuffix."')", $strQuotedPrintable); }

in Send()

if ($objMessage->Subject){ $strSubjectQuoted = str_replace( "=\r\n", '', //needs not chunked lines, but quoted ones. self::QuotedPrintableEncode($objMessage->Subject, true)); $strEncodedWordsSubject = self::GetEncodedWordChunks($strSubjectQuoted, $strEncodingType); fwrite($objResource, "Subject: $strEncodedWordsSubject\r\n"); }

tested and verified with qcubed 2.0.2, PHP 5.3.10

Sorry there is a typo:

(the string from =? to =?, including those limiters)

should read

(the string from =? to ?=, including those limiters)

I've had my fair share of trouble with QEmailServer too in the past two days and one bug that i encountered was with long subject lines.

According to  http://www.ietf.org/rfc/rfc2047.txt a quoted-printable encoded-word "Subject" must be split into chunks of max. 75 characters.

So instead of

Subject: =?UTF-8?Q?something_very_long?=

it must be split into

Subject: =?UTF-8?Q?something?= =?UTF-8?Q?very_long?=

where each of those encoded-word "atoms" must not exceed 75 characters (the string from =? to =?, including those limiters).

It seemed weird but after what I've seen regarding emails and encodings today and a little desperateness I gave it a try and to my surprise the subjects were displayed correctly, even very long ones.

I haven't yet created some generic code to fix this.
Maybe it would be a good idea to use B (base64) by default instead of quoted_printable. From some other people's experiences that i read in forums it seems as you don't have this hassle with having to make chunks there. But i haven't tested it.

Also i have used michaelarnauts patches successfully to resolve the other problems he mentioned.

Initial version, way unfinished.

Other adapters seem to be affected too. But, since I don't run those database adapters, I cannot test them.

QCubed already requires that ids only be alpha numeric, even though html allows underscores and dashes. As far as wrapper controls, yes, it would prevent you from specifying a wrapper as a handle if you only gave it the control name. The easy workaround is to include the '#' on front of the wrapper id, as in '#myControl_ctl'.

The bigger question is if we detect that it is a QCubed control id because it is only alpha numeric, should we then look to see if that control has a wrapper and then use the wrapper instead as the handle. Not sure. Will require some testing.

Currently all database 'Gen' classes are being created with NULL defaults constants.

For example in our table, we have a column named UserName with a default of 'Guest'. In the TableNameGen class file, there is a constant being created named UserNameDefault being set to NULL. However, it should be set to 'Guest'.

I have a fix for MySqli adapter. Line 566 in QMySqliDatabase.class.php QMySqliDatabaseField::__construct(), add right after if ($objRow["Field"] == $this->strOriginalName) {

$this->strDefault = $objRow["Default"];

After adding this, we are able to use the constant TableName::UserNameDefault, and $objTableName->Initialize() works as expected.

I have to work on learning how to generate and upload a diff.

duplicate:

Dup of #816 which is fixed in 2.1.1

milestone changed