Search options (Page 40 of 200)

Thanks for pointing this out.
We are no longer supporting release 2.3, but for those still using it they could just set the value $use_costed_values to 1 instead of 0 in config.php.

For backwards compatibility in 2.4 we will just change the value $use_costed_values to 1 in config.default.php, so all new users will automatically get this option.

Should they prefer the old method for some reason, they can set this value to 0.

Thanks @boxygen for helping with this.

/Joe

Are you updated with the latest repo build. I vannot reproduce this error, either on screen or in rep601.php report.
Everything is ok.

However we are planning an upgrade to 2.4.2, due to a couple of bugs.

/Joe

Ok, sorry my mistake. Then it is per default set to 1 in the sys_pref class. That is to say that the $SysPref->use_date_picker is set to 1 per default.

/Joe

In 2.4 all the global defined variables in config.php is assembled into the global $SysPrefs variable, so the name of the global variables is now $SysPrefs->use_date_picker. Then we only need to declare the $SysPrefs variable as global.
However if you are using the old $use_date_picker in an extension and you declare this as global in your routines is should work adequate.
For simplicity we have surrounded the new global members by macros, like user_use_date_picker();

There should be no occurrencies of the old $use_date_picker in the core, besides the one in config.php.

/Joe

Yes, but if you want to select a period less than a month this will not work. For those who absolutely want this to work on a monthly base, then it could be done this way.

Joe

Janusz will have a look at this. Sounds like a good idea.

Joe

I think I will commit these files now. I have tested them without any problems.

/Joe

Yes, you are right. The internal variable was not zeroed out before use in the Suppliers. Thanks for detecting this.

It will be committed asap to 2.4 stable repo.

In the meantime you can download the /includes/dashboard.inc and replace it in your setup.

/Joe

The implemented algorithm is the fastest way of doing it. In C/C++ these check are internally converted to assembly instructions of one line.

Still, I am waiting for test result before committing it to 2.4. And as told, it is possible to use the files in 2.3.X also as the code are the same in both releases and files. Only you will have to replace the files yourself.

/Joe

@boxygen

You could look in the CHANGELOG.txt file. It will give an overview what has been changed and the files changed. You should go back and start at the 2.4 RC release and look upwards

For detailed changes, you can also look in the Git repo on Sourceforge.net, branch unstable.

Git repository

/Joe

@nashirbadu

I have included 2 files for testing of large files with more than 65535 rows. These files are only for testing, so DO NOT use them in production yet.

Will you download the files, rename Workbook.php1 to Workbook.php and replace the files in /reporting/includes folder.
Backup your original files during testing.

These files work with both small and large files with over 65530 rows. I have tested with 100000 rows without problem.
It will take some time with 100000 rows, about 2-3 minutes or more.
It works the way that when reaching the max row files, 65530, a new sheet is established and the rows roll over to this new sheet and so forth.

Please tell me if the files are ok.

In the file, excel_report.inc up at the top there is a define('MAX_ROW_SHEET', 65530);
You can, for testing, use a lower value, say 25,  and see the changing to a new sheet.

/Joe