ScriptCase v8.0.042 (04-27-2015 14:04)

Specific correction

  • Fixed issue in the positioning of background images in PDF Report with RTL languages ​​(right-to-left).
  • Fixed problem in “Clean” button behavior of the filter when used in special conditions.
  • Fixed issue in the search engine of the filter application, when you have more than one table.

Bug

  • Fixed issue in the behavior of the macro sc_alert during navigation in the Grid application.
  • Fixed connection problem in the Log Module when application has different connection from the module one.
  • Fixed tabulation problem in the Grid application when it has only one field as Group By.
  • Fixed issue in the view content in the Grid applications when it start by the summary and it has a nested Grid enable.
  • Fixed issue in the menu application when there is a validation on the menu items.
  • Fixed problem accessing side menu settings in the PDF Report application.
  • Fixed problem when using the macro sc_error_message in master / detail application.
  • Fixed issue in display the main menu at lower resolutions.

Hi John,

I updated this automatically from scriptcase itself, update done, updated to v .42 but the “edit fields” screen now doesn’t work! whatever you change in the fields as “mass change of type of (required)” after the save it returns to the initial status!

1- although, type can be changed from each field individually as a workaround, but the “required” option of the field is only in that screen, which is not working!
2- the manual download from the site still gives the the .41 version, not .42

[QUOTE=MikeDE;36096]
2- the manual download from the site still gives the the .41 version, not .42[/QUOTE]

You can manually change the download link to .42 to get the newest version

Joe

Joe, it is exactly the same size of .41 zip package (260.338 Mb) , I don’t think your trick will work!! can you check it closer!?

I usually keep the older zip packages so to revert back if essential issue appears in the new version!

bug in generation of code

The following code refuses to work if you apply a field with the same name of a variable:


$check_sql = "SELECT returnurl, reporturl, rtlo FROM ndshoppreferences where  shopid='".{shopid}."'";
sc_lookup(rs, $check_sql);

if (isset({rs[0][0]}))     // Row found
{
    $returl = {rs[0][0]};
	$repurl = {rs[0][1]};
	$rtlo   = {rs[0][2]};
	$invoice="{shopid}{origin}{invoiceid}";
        $invoice = str_replace(' ', '', $invoice);
	$amount = {amountincltax}*100;
	$url='https://www.targetpay.com/ideal/start?rtlo='.$rtlo.   <<<<================================= this variable generates a php error 'Undefined variable: rtlo'
		 '&reporturl='.$repurl.'/blank_reporturl/blank_reporturl.php?token='.[glob_logincode].
	  	 '&returnurl='.$returl.'/return_url/return_url.php?token='.[glob_logincode].
		 '&bank='.{Bank}.
		 '&description='.$invoice.
		 '&amount='.$amount.
		 '&language=nl'.
		 '&test=0'.
		 '&ver=3';


If you look into the generated code you’ll find:


if (isset($this->rs[0][0]))     
1641| {
1642|     $returl = $this->rs[0][0];
1643|     $repurl = $this->rs[0][1];
1644|     $this->rtlo   = $this->rs[0][2];
1645|     $invoice="$this->shopid $this->origin $this->invoiceid ";
1646|     $invoice = str_replace(' ', '', $invoice);
1647|     $amount = $this->amountincltax *100;
1648|     $url='https://www.targetpay.com/ideal/start?rtlo='.$rtlo.
1649|          '&reporturl='.$repurl.'/blank_reporturl/blank_reporturl.php?token='.$this->sc_temp_glob_logincode.
1650|            '&returnurl='.$returl.'/return_url/return_url.php?token='.$this->sc_temp_glob_logincode.
1651|          '&bank='.$this->bank .
1652|          '&description='.$invoice.
1653|          '&amount='.$amount.
1654|          '&language=nl'.
1655|          '&test=0'.
1656|          '&ver=3'; 

Obviously 4| $this->rtlo = $this->rs[0][2]; is another variable then $url=‘https://www.targetpay.com/ideal/start?rtlo=’.$rtlo.

This is a bug that existed before, was solved and appearantly re-introduced?

[QUOTE=aducom;36105]

This is a bug that existed before, was solved and appearantly re-introduced?[/QUOTE]

this is the nightmware I’m trying to explain over and over, we always get this stuff, i was on .34 seems ok, then found later that they added new themes so i’m interested and updated the version

now i have a table with over 400 fields but i can’t save from “Edit Fields” screen! nothing is being saved, I assued because the large number of the fields but obviously it is not, i changed the maxvar in php.ini to 10000000 doesn’t save!!

anyone knows how to make fields “required” from other place of sc? that is the only screen which we can control the required fields guys, it is not saving!

Hello,

We will check the problems, if detected, we can release a new update today or tomorrow.

[QUOTE=MikeDE;36096]Hi John,

I updated this automatically from scriptcase itself, update done, updated to v .42 but the “edit fields” screen now doesn’t work! whatever you change in the fields as “mass change of type of (required)” after the save it returns to the initial status!

1- although, type can be changed from each field individually as a workaround, but the “required” option of the field is only in that screen, which is not working!
2- the manual download from the site still gives the the .41 version, not .42[/QUOTE]

Hello Mr. Mike,

We are trying to simulate the problem, but we are not succeeding. It would be possible to make some remote access?
If not, let us know about your environment with a walkthrough or send us some pictures with more details about the problem.
I tried to send an email to the email registered on the forum, but was refused.

Hi John,

okay in the php.ini the max_input_vars put to 60000 as explained in the email and it worked, I seemed having losts of fields!

I would like to thank you and appreciate your quick response, also your quick interference, that means a lot to all of us.

Hopefully Albert problem gets resolved too, as he says, we found many times small old bugs re-appear after the upgrade which make us uncomfortable, I’m one of the people who keep all the versions as zip file as well so to revert back in case of old bugs jump again!

Thanks a lot
cheers

[QUOTE=aducom;36105]The following code refuses to work if you apply a field with the same name of a variable:


$check_sql = "SELECT returnurl, reporturl, rtlo FROM ndshoppreferences where  shopid='".{shopid}."'";
sc_lookup(rs, $check_sql);

if (isset({rs[0][0]}))     // Row found
{
    $returl = {rs[0][0]};
	$repurl = {rs[0][1]};
	$rtlo   = {rs[0][2]};
	$invoice="{shopid}{origin}{invoiceid}";
        $invoice = str_replace(' ', '', $invoice);
	$amount = {amountincltax}*100;
	$url='https://www.targetpay.com/ideal/start?rtlo='.$rtlo.   <<<<================================= this variable generates a php error 'Undefined variable: rtlo'
		 '&reporturl='.$repurl.'/blank_reporturl/blank_reporturl.php?token='.[glob_logincode].
	  	 '&returnurl='.$returl.'/return_url/return_url.php?token='.[glob_logincode].
		 '&bank='.{Bank}.
		 '&description='.$invoice.
		 '&amount='.$amount.
		 '&language=nl'.
		 '&test=0'.
		 '&ver=3';


If you look into the generated code you’ll find:


if (isset($this->rs[0][0]))     
1641| {
1642|     $returl = $this->rs[0][0];
1643|     $repurl = $this->rs[0][1];
1644|     $this->rtlo   = $this->rs[0][2];
1645|     $invoice="$this->shopid $this->origin $this->invoiceid ";
1646|     $invoice = str_replace(' ', '', $invoice);
1647|     $amount = $this->amountincltax *100;
1648|     $url='https://www.targetpay.com/ideal/start?rtlo='.$rtlo.
1649|          '&reporturl='.$repurl.'/blank_reporturl/blank_reporturl.php?token='.$this->sc_temp_glob_logincode.
1650|            '&returnurl='.$returl.'/return_url/return_url.php?token='.$this->sc_temp_glob_logincode.
1651|          '&bank='.$this->bank .
1652|          '&description='.$invoice.
1653|          '&amount='.$amount.
1654|          '&language=nl'.
1655|          '&test=0'.
1656|          '&ver=3'; 

Obviously 4| $this->rtlo = $this->rs[0][2]; is another variable then $url=‘https://www.targetpay.com/ideal/start?rtlo=’.$rtlo.

This is a bug that existed before, was solved and appearantly re-introduced?[/QUOTE]

Hi aducom.

Can you tell me what application and event did you use?

[QUOTE=c.vinicius;36122]Hi aducom.

Can you tell me what application and event did you use?[/QUOTE]

This was part of button code in a control application. Clicking on the button should direct the user to an electronic payment gateway, but this goes - obviously - wrong. I managed to get it running by solving the conflicting names.

Hi Albert.

In fact, Scriptcase creates a variable with the same name of table’s field. For example, if you have a field called ‘xxx’, the Scriptcase will create a variable $xxx. It might be better if the scriptcase use a prefix in the variables to avoid this kind of conflict.