visual studio 2015 c error c2664

[Risolto] Error C2664 HMODULE LoadLibraryW(LPCWSTR) cannot convert parameter to LPCWSTR

Stavo implementando un AudioWrapper per lavorare con FMOD e OpenAL cambiando implementazione senza dover riscrivere il codice. Aggiungendo l’integrazione di OpenAL, seguendo la documentazione e i file di esempio, provo a compilare e sorpresa:

 

LoadOAL.cpp error C2664: ‘HMODULE LoadLibraryW(LPCWSTR)’: cannot convert argument 1 from ‘char *’ to ‘LPCWSTR’

 

visual studio 2015 c error c2664

 

Bello! Il problema sorge perchè di default il mio ide (Visual Studio 2015) aveva impostato il set dei caratteri del progetto a “Unicode Character Set” e cosi facendo le funzioni di Windows pretendevano una stringa in formato LPCWSTR (Long Pointer to Const Wide String).

Ci sono due possibili opzioni per risolvere il problema:

  1.  Modificare il codice e fare un reinterpret_cast a LPCWSTR
  2. Cambiare il set di caratteri del progetto per farlo matchare

Nel mio caso il codice incriminato era del framework di OpenAL e quindi non volevo metterci mano per una questione di mantenibilità e design. Ho optato quindi per il semplice cambio del set di caratteri!

 

Come si fa ? È facilissimo! 🙂

  1. Dal pannello “Solution Explorer” cliccate col destro sul vostro progetto e dal menu contestuale andate sulle proprietà del progetto
  2. Andate nel tab “General” (dovrebbe essere il primo, di default)
  3. In fondo tra i default del progetto cercate l’opzione “Character Set” e cambiate il suo valore da “Use Unicode Character Set” a “Use Multi-Byte Character Set”.
  4. Salvate (occhio di farlo per tutte le configurazioni e piattaforme per cui dovete compilare!)
  5. Enjoy! 🙂 Gli errori dovrebbero essere scomparsi

visual-studio-2015-change-character-set

 

 

Spero sia utile, io fortunatamente non ci ho sbattuto la testa troppo.

 

Arkanoid in C++ & DirectX 11

Ho utilizzato la pausa estiva per concentrarmi sul Master che sto seguendo (Master in Computer Game Development), volevo provare a scrivere un articolo al giorno … e invece alla fine ho scritto un articolo al mese! 😀 Fa niente, questo è un hobby e tale deve rimanere.

Volevo condividere con il mondo e con quei 4-5 che leggono un giochino (clone del Famoso Arkanoid) che ho sviluppato per gli esami (era un combo) di Advanced C++ e di Graphics Programming.

Il gioco è stato scritto interamente in C++ utilizzando le DirectX 11 come API per il rendering della grafica. Ho usato solo una libreria esterna, “stb_image.h” un singolo file .h da includere per leggere i dati delle immagini (texture) da caricare nel gioco.

 

La build è solo per Windows e la trovate a questo link: https://github.com/Pes8/FakeArkanoid-Game/releases/tag/1.0

C++ FakeArkanoid
Screen Shot di una partita del gioco. Livello 0.

 

Per i codici sorgenti trovate tutto su github: https://github.com/Pes8/FakeArkanoid-Game

Piccolo video di gameplay: https://www.youtube.com/watch?v=b70Rh7EpyUI

 

Se avete suggerimenti e/o bug fatelo pure via email, su github o come commento qui sotto 🙂

 

Hasta la vista

 

[Laravel] Convertire stringhe vuote in “NULL” dei input form

In laravel i campi di qualche input form se lasciati vuoti vengono ritornati al modello sottoforma di stringa vuota ( “” ), questo può essere un problema per esempio se viene fatto l’inserimento a DB e quel campo rappresenta una chiave esterna verso un’altra tabella che può essere null ma non ”.

Per esempio, io ho avuto la necessità di cambiare il comportamento, altrimenti MySQL mi tornava un bel errore:

 

SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails

 

Perchè come ben sapete il valore NULL è diverso da stringa vuota ” e quindi l’inserimento del modello a db falliva.

Per risolvere è possibile creare un nuovo middleware che filtra tutti gli input in ingresso dai form inviati e setta a NULL i campi interessati.

 

  1. Crea un nuovo file nella cartella app/Middleware col nome NullableFields.php
  2. Incolla questo codice [Laravel 5.2] :
<?php
namespace App\Http\Middleware;
use Closure;

class NullableFields {

    public function handle($request, Closure $next){

        $input = $request->all();

	    if($input){
	        array_walk_recursive($input, function (&$item){   
	            $item = trim($item);
	            $item = ($item == '')? null : $item;
	        });

	        $request->merge($input);
	    }

	    return $next($request);
	}

}

La classe non è altro che un semplicissimo middleware custom che fa il check sui campi della richiesta e setta a null eventuali stringhe vuote!

 

Infine per farlo funzionare va aggiunto all’array $middleware dentro al file “app\Http\Kernel.php”

English Version of the Article: Converting Empty String to NULL

Modificare il PHP Time Limit (max_execution_time) su hosting condiviso

Avete bisogno di aumentare (o modificare) il max_execution_time dei vostri script php ?

Oppure qualche tema di wordpress (come ad esempio Avada) vi richiede un PHP Time Limit di 300 secondi per funzionare correttamente ?

E magari siete su un hosting condiviso senza nessuna possibilità di modificare il file php.ini con i vari settaggi ??

 

NO PROBLEMA!

 

Questa è la soluzione:

 

ini_set(‘max_execution_time’, 300);

 

Dove 300 è il tempo, espresso in secondi, che volete impostare! Questa semplice riga di codice modifica solo temporaneamente (per l’esecuzione dello script) l’impostazione, quindi è una tua configurazione locale e per singolo script! Il trucco sta nel inserirlo in ogni file php che necessita di tale impostazione.

Nel caso di wordpress si può inserire in alto nel file wp-config.php che viene incluso, e quindi eseguito, da ogni script di wordpress!

Facile no ? 🙂

PHP7 su Server Linux e Microsoft SQL Server su Server Windows (Parte 2 – pdo_odbc)

Prosegue l’avventura, dopo aver provato con sfortuna ad utilizzare il driver pdo_dblib per connettermi al database microsoft sql server e aver fallito miserabilmente per i problemi descritti in quell’articolo, spinto più per curiosità che per speranza, decido di provare a utilizzare il driver pdo_odbc per connettermi a quel maledetto Database Microsoft SQL Server su macchina windows dal mio bel server Linux con PHP7.

 

Questo driver è stato più difficile da installare e configurare.

Ho dovuto invece installare unixodbc e tdsodbc e configurare i seguenti file: “/etc/odbc.ini”, “/etc/odbcinst.ini” e “/etc/freetds/freetds.conf” (ovviamente i percorsi dipenderanno dal vostro sistema operativo) Se avete difficoltà potete trovare informazioni utili a questa domanda (prima risposta) su stackoverflow: http://stackoverflow.com/questions/20163776/connect-php-to-mssql-via-pdo-odbc

Dopo aver smanettato abbastanza però arriva LA LUCE e riesco anche così a connettermi al DB e a chiamare le stored procedure. Anche qui a primo impatto sembra funzionare a dovere …

Finchè non scopro che invece di eseguire delle semplici “EXEC stored_name @stored_param_name_1 = param_1_value,  @stored_param_name_2 = param_2_value […]” faceva delle porcate allucinanti e sporca tantissimo le chiamate al DB.

 

Non ho continuato ad indagare, non era ammissibile una cosa del genere. Aspetterò che Microsoft rilasci i driver aggiornati per PHP7. Per ora sono disponibili solo per Windows.

Per linux solo una speranza di sviluppo futuro: https://github.com/Azure/msphpsql/issues/58

 

È stato divertente anche se l’esperimento è fallito. È stato deciso quindi infine di rimanere su PHP5 e attendere nuovi sviluppi di driver per MSSQL su PHP7.

 

Hasta pronto amigos!

PHP7 su Server Linux e Microsoft SQL Server su Server Windows (Parte 1 – pdo_dblib)

L’altro giorno stavo facendo dei test su un server linux pulito, installato a nuovo con PHP7, per connettermi e comunicare con un database Microsoft SQL Server.

La situazione: Gestionale su server linux con installato PHP e database microsoft sql su server windows. Come tutti sanno i due sistemi non vanno molto d’accordo tra loro.

 

È stato un bagno di sangue.

 

L’esigenza nasceva da voler migrare da php 5.x a alla versione 7.x per restare aggiornati e sfruttarne le nuove features, peccato che con php7 sono arrivate anche molte brutte novità! Come ad esempio la cancellazione di alcune estensioni utilizzatissime:

 

  • ereg
  • mssql
  • mysql
  • sybase_ct

 

Stavo continuando lo sviluppo di un gestionale con CodeIgniter 3.x (dopo la migrazione) che utilizzava l’estensione mssql come driver per la libreria per connettersi e comunicare col database microsoft.

All’inizio non credevo fosse un cambio così drastico, ho pensato: “vabbeh, ci saranno altre estensioni/librerie etc”. Così ho iniziato a vedere con l’estensione PHP PDO (visto che era uno dei driver supportati da CI3)  che possibilità ci fossero:

 

Driver name Supported databases
PDO_CUBRID Cubrid
PDO_DBLIB FreeTDS / Microsoft SQL Server / Sybase
PDO_FIREBIRD Firebird
PDO_IBM IBM DB2
PDO_INFORMIX IBM Informix Dynamic Server
PDO_MYSQL MySQL 3.x/4.x/5.x
PDO_OCI Oracle Call Interface
PDO_ODBC ODBC v3 (IBM DB2, unixODBC and win32 ODBC)
PDO_PGSQL PostgreSQL
PDO_SQLITE SQLite 3 and SQLite 2
PDO_SQLSRV Microsoft SQL Server / SQL Azure
PDO_4D 4D

 

PDO_SQLSRV: “The PDO_SQLSRV extension is only compatible with PHP running on Windows. For Linux, see ODBC and » Microsoft’s SQL Server ODBC Driver for Linux.” -> SCARTATO.

 

Le alternative rimaste erano 2: PDO_DBLIB che a basso livello utilizza la libreria FreeTDS e PDO_ODBC che utilizza comunque la libreria FreeTDS.

ODBC non mi è mai stato simpatico quindi ho iniziato installando la libreria FreeTDS (pacchetto freetds-dev) e il driver pdo_dblib.

Dopo un po’ di configurazioni riesco a connettermi e a utilizzare il DB! Paginetta di prova in PHP7 sembra funzionare, ho dovuto sistemare un po’ la libreria che gestiva le connessioni e chiamate al DB del framework, giustamente, perchè alcune funzioni dovevano essere chiamate diversamente o restituire un oggetto diverso ma niente di complicato/lungo.

Ero quasi contento … finchè non scopro alcuni “problemini”:

 

  1. La funzionalità per bindare i parametri per una chiamata a Stored Procedure non ha il bind dei nomi direttamente sulla chiamata, ma è legato solo alla preparazione della query che quindi ha un ordinamento ben preciso! Questo vuol dire che prima l’ordine del bind dei parametri non era importante perchè venivano sincronizzati direttamente dal driver con il rispettivo parametro della stored procedure e quindi le chiamate alle stored sono sempre state fatte senza pensarci. Avrei dovuto controllare tutte le chiamate (molte, troppe) per verificare l’ordinamento dei parametri …. due palle!
  2. I valori nei recordSet del risultato di una chiamata sono castati tutti a stringa! Prima interi, float etc risultavo del tipo giusto nei recordset di output e quindi all’interno del framework/gestionale venivano trattati come tale! (ad esempio controlli di uguaglianza con check del tipo es:”===” oppure sputati fuori in API utilizzate da applicazioni esterne etc). Anche qui avrei dovuto fare un check + refactoring completo … altre 2 palle!

 

Queste due complicanze tutto sommato non erano insormontabili, semplicemente un po’ noiose e avrebbero richiesto un paio di giornate in più. Nulla di impossibile. Però, qui c’è il però finale, non era tutto! Ho smadonnato un altra ora buona su un altro problema.

 

  • In caso di risultati della query con più recordset (o rowset come volete chiamarli) c’erano dei problemi che non riuscivo a capire … a volte il passaggio da un recordset al successivo passava liscio, a volte faceva errore restituendo poi tutti recorset vuoti (anche se in realtà a db le tabelle del risultato c’erano!)

L’errore che faceva era: “SQLSTATE[HY000]: General error: PDO_DBLIB: dbresults() returned FAIL"

E io non capivo come mai … ho letto tutta la documentazione, andato in giro su stackoverflow cercando compagnia ma nulla. Finchè non mi viene in mente di fare qualche prova in più e scopro una cosa ASSURDA!

In caso di risultati con più recordset se io scorro il recorset attuale utilizzando il metodo PDO::fetchAll() per fetchare tutte le righe insieme non c’è nessun problema e la chiamata PDO::nextRowset() funziona normalmente. Invece se scorro il recordset con PDO::fetch() DEVO ASSOLUTAMENTE arrivare alla fine e cioè finche il metodo non restituisce FALSE! Se il metodo non restituisce false per dirti che sei arrivato alla fine allora la chiamata a PDO::nextRowset() fallirà mostrandoti il messaggio di errore precedente! ASSURDO!

Anche perchè spesso il primo recordset nel mio caso era solo di controllo (Campo errore con eventuale campo messaggio) quindi eseguivo solo una volta il fetch, sapendo a priori che avrei avuto solo una riga in quel recordset e in questo modo PDO::nextRowset() falliva! Dovevo quindi OBBLIGATORIAMENTE chiamare due volte il metodo PDO::fetch() perchè così alla seconda restituiva false, la libreria era contenta e finalmente si spostava di rowset!

Ho risposto anche a una domanda su stackoverflow a riguardo, se siete interessati questo è il link: http://stackoverflow.com/questions/38012890/pdo-dblib-nextrowset-not-working/

Troppi ostacoli, troppe rogne. Ho lasciato perdere e per sfizio ho provato allora a utilizzare il driver pdo_odbc su php7 e database microsoft sql server

Fare il versionamento dei modelli con Laravel

Come già accennato di qua e di là sto sviluppando un gestionale clienti per aziende nel settore termoidraulico. Nella nuova versione del gestionale voglio includere facilmente il versionamento (ossia la storia delle modifiche) avvenute a livello database dei modelli (ad esempio l’anagrafica cliente, gli interventi etc) in modo che si possano vedere tutte le modifiche effettuate ai dati e anche possibilmente chi (quale utente) le ha fatte. In questo modo si ha il totale controllo sui dati e non si rischia di perdere nulla. Inoltre si può anche tenere sotto controllo le eventuali impiegate poco precise!

 

Utilizzo Laravel 5.1 come framework di partenza e ho scoperto un suo package molto interessante: Revisionable di VentureCraft !

Questo package fa tutto quello che volevo, tiene traccia delle modifiche effettuate ai dati dei modelli scelti con anche le informazioni su chi ha effettuato la modifica! Fantastico 🙂

I passi da seguire per installarlo sono pochi:

 

Aggiungere la seguente riga al fiel composer.json del progetto laravel:

“venturecraft/revisionable”: “1.*”

Eseguire l’update di composer:

composer update

E infine migrare le tabelle del package utilizzando artisan:

php artisan migrate –path vendor/venturecraft/revisionable/src/migrations

(Attenzione che nella guida ufficiale si fa uso dell’opzione –package di artisan che non è più disponibile dalla versione 5 di laravel. È quindi necessario andare a cercare la cartella dove è presente la migrazione e utilizzare l’opzione –path, come nel mio esempio)

 

Quasi fatto!

 

Ora che abbiamo installato e migrato con successo il pacchetto per tenere traccia della storia delle modifiche sul database dobbiamo modificare i modelli di laravel per utilizzare revisionable, sarà sufficiente aggiungere il suo namespace e utilizzare il trait corrispondente:

namespace MyApp\Models;

class Article extends Eloquent {
use \Venturecraft\Revisionable\RevisionableTrait;

public static function boot(){
parent::boot();
}
}

 

Bene! Abbiamo impostato il pacchetto revisionable per fare il versionamento dei nostri modelli e delle modifiche sul database 🙂 Ora per visualizzare la storia delle modifiche è sufficiente richiamare il metodo:

$article = Article::find($id);
$history = $article->revisionHistory;

Ad esempio, in una view (vista) possiamo visualizzare lo storico dei cambiamenti così:

@foreach($article->revisionHistory as $history )
<li>{{ $history->userResponsible()->first_name }} changed {{ $history->fieldName() }} from {{ $history->oldValue() }} to {{ $history->newValue() }}</li>
@endforeach

 

Lo so che sono stato poco preciso e frettoloso ma ho avuto poco tempo per scrivere il tutto, in ogni caso basta seguire la documentazione ufficiale per utilizzare questo bellissimo (e utilissimo) pacchetto!

Alla prossima!

Come fare la tilde (~) su Windows

Per chi non è nel campo informatico può essere difficile capire come scrivere il carattere tilde “~” con la tastiera italiana sul sistema operativo windows.

In realtà è facilissimo! Per scrivere un carattere speciale, come la tilde, su windows possiamo usare la combinazione di tasti ALT + numeroIdentificativo.

Il numero identificativo per la tilde è 0126 quindi la combinazione da fare sarà “ALT + 0126“, lo zero iniziale si può evitare scrivendo semplicemente 126. ATTENZIONE che i numeri devono essere scritti con il tastierino numerico.

Qui c’è una tabella con alcuni codici più comuni utilizzati:

scorciatoia-tastiera-caratteri-speciali-windows

 

NB: per chi è alle prime armi: il + nella combinazione significa che devi mantenere premuto il tasto ALT e premere successivamente le cifre corrispondenti.

Visualizzare i warnings dalla linea di comando di MySQL

Durante la migrazione del DB di cui parlo nell’articolo riguardo rinominare le tabelle in MySQL da minuscolo a maiuscolo su Windows ho notato che erano presenti dei warnings su alcune istruzioni/query.

Da linea di comando del nostro client MySQL possiamo attivare la visualizzazione diretta dei warning digitando semplicemente il comando “\W”:

mysql> \W

Show warnings enabled.

 

per ri-disabilitarli invece il suo gemello “\w” (notare che questo è minuscolo):

mysql> \w

Show warnings disabled.

Per visualizzare invece i warnings passati dove non era abilitata la visualizzazione possiamo recuperarli grazie alle istruzioni:

SHOW WARNINGS [LIMIT [offset,] row_count] -> Visualizza gli ultimi warnings
SHOW COUNT(*) WARNINGS -> Ritona il numero di warnings memorizzati.

Occhio che è possibile visualizzare solo i warnings riferiti all’ultima istruzione/query eseguita!

Per approfondire la questione c’è sempre la buona documentazione ufficiale: http://dev.mysql.com/doc/refman/5.7/en/show-warnings.html

Rinominare tabelle in MySQL da minuscolo a maiuscolo

Inauguro questa sezione (che conterrà indicazioni tecniche molto brevi, delle pillole) con una chicca sul database MySQL.

Stavo migrando un database MySQL di un gestionale clienti da me sviluppato per un’azienda nel settore termotecnico / idraulico in cui tra le tante cose ci sono anche alcune rinominazioni delle tabelle dove la prima lettera passa da lowercase ad uppercase (da minuscolo a maiuscolo).

Mi sono accorto che i nomi delle tabelle rimanevano invariati anche se davo il comando corretto:

ALTER TABLE clienti RENAME Clienti;

Ma la tabella rimaneva sempre “clienti”.

Come mai questo ? Me lo sono chiesto anche io è il motivo è il seguente:

In MySQL, databases correspond to directories within the data directory. Each table within a database corresponds to at least one file within the database directory (and possibly more, depending on the storage engine). Triggers also correspond to files. Consequently, the case sensitivity of the underlying operating system plays a part in the case sensitivity of database, table, and trigger names. This means such names are not case sensitive in Windows, but are case sensitive in most varieties of Unix. One notable exception is OS X, which is Unix-based but uses a default file system type (HFS+) that is not case sensitive. However, OS X also supports UFS volumes, which are case sensitive just as on any Unix.

 

Ta-dah! In pratica (giustamente) MySQL rimanda la gestione dei file che corrispondono alle tabelle al sistema operativo quindi in caso di Windows (dove effettivamente girava il servizio) i nomi delle tabelle sono case insensitive (nessuna differenza tra minuscolo/maiuscolo CLIENTI == clienti)!

Si può modificare questo comportamento andando a settare la variabile di sistema MySQL  “lower_case_table_names"

Valore Significato
0 I nomi delle tabelle e dei database sono memorizzati sul disco usando le lettere specificate durante l’istruzione CREATE TABLE o CREATE DATABASE. La comparazione dei nomi è case sensitive (tiene conto del maiuscolo o minuscolo). Non bisogna settare a 0 questa variabile se MySQL gira su un sistema case-insensitive (Come Windows o OS X). Se viene forzata a 0 su questi sistemi si possono corrompere gli indici per tabelle MyISAM.
1 I nomi delle tabelle e dei database sono memorizzati sul disco utilizzando solo le lettere minuscole e il confronto dei nomi è case insensitive (non tiene conto del maiuscolo o minuscolo). MySQL converte tutte le tabelle in minuscolo nella memorizzazione e nel lookup. Questo comportamento si applica anche agli alias delle tabelle.
2 I nomi delle tabelle e dei database sono memorizzati sul disco usando le lettere specificate durante l’istruzione CREATE TABLE o CREATE DATABASE ma MySQL converte tutto in minuscolo al momento del lookup. Il confronto dei nomi rimane case-insensitive. Questo comportamento funziona solo su file systems che non sono case sensitive! I nomi delle tabelle InnoDB sono memorizzati in minuscolo come per lower_case_table_names=1.

Scoperto quindi l’arcano! Per quanto mi riguarda non ho modificato il comportamento di MySQL e ho quindi ignorato il comportamento (mantenendo negli script per la migrazione la rinominazione in modo che se migreremo su un sistema operativo tipo UNIX non ci saranno sorprese).

Questo è tutto, spero che sia servito a qualcuno che come me non sapevo di questo comportamento e si chiedeva come mai su windows MySQL non rinominasse le tabelle con il nome maiuscolo anche se il comando era corretto!

Per approfondire la questione rimando direttamente alla documentazione ufficiale: http://dev.mysql.com/doc/refman/5.7/en/identifier-case-sensitivity.html

Primo articolo – Cosa voglio fare

Ok, il blog era vuoto … così devo fare almeno un primo articolo.

Sparo due cose a caso per riempire un po’ 😀 No dai, ti parlo di cosa voglio parlare in questo blog.

Intanto subito alcune chicche, a breve arriveranno tutorial/articoli su questi argomenti:

  • Sviluppo BOT Telegram in PHP (Laravel + Telegram Bot API PHP SDK)
  • Come ricevere un certificato SSL valido (non self-signed) per 90 giorni completamente GRATIS (necessario per il bot telegram, per esempio 😀 )
  • Configurare un VPS (Virtual Private Server) per hostare siti web con wordpress

Spero sia roba interessante, sennò amen … poco mi frega.

Devo ancora strutturare il blog con categorie, sottocategorie etc. Sto cercando di capire bene che taglio voglio dargli. Inoltre vorrei tentare di fare qualcosa di abbastanza tecnico e non fare i soliti articoletti per noob o finti programmatori.

 

Vediamo come va 🙂

 

Intanto grazie, lettore, se sei arrivato fin qua. Mi scuso subito per la mia scrittura: non sono mai stato bravo a scuola con i temi 🙂 Spero di migliorare man mano.

 

Adios!