You're welcome Kermit... ops, sorry, Adrian. :-)
P.S. You can use Gravatar to place your own image here in the forum. :-)
You're welcome Kermit... ops, sorry, Adrian. :-)
P.S. You can use Gravatar to place your own image here in the forum. :-)
Hello Adrian,
Yes; I think you search for "window.App.RootScope.TableHTML".
Hello Jordi,
Thanks for sharing with us. Certainly, the Audio object is interesting, and, almost perfect to place a background audio in our apps. Note that we can use the object's instance variable too in other possibles ways, to stop the audio, play it, etc. The app in which you implement the Audio object is algo very good, you can link it here! Anyway, you know that I plain to add it into the DecSoft blog like a very good usage example of App Builder. :-)
Hola Jordi,
Gracias por compartirlo aquí. Ciertamente, el objeto Audio es curioso, y, de hecho, si tenemos cuidado con la variable que usamos, podremos usarla también a lo largo de la app, quiero decir, alguno de los métodos del objeto, para parar el audio, continuar con su reproducción, etc.
La app para la que lo has hecho también ha quedado muy chula, si quieres puedes poner enlaces aquí mismo, y, en todo caso, ya sabes que voy a ponerla en el blog de DecSoft como ejemplo de uso de App Builder. :-)
Hello Amin,
Wow... thanks very much for your kindly words. I really appreciate it. :-)
Hello to all,
Here is a new DecSoft App Builder release, with the below changes, fixes and enhancements:
Hello Amin,
Certainly "test" is taken as a variable, so you are right. It's not exactly a bug, but, the expected behaviour right now. I want to take a look at this, Amin, maybe we can find a proper way to enhance it.
Hello Amin,
I am sorry for the possible inconveniences. Certainly there is a bug in the ObjectGetProp action, if we use it inside an AB function with an object created before. This bug is fixed now, so please, update your AB copy and try it, Amin. Again sorry for the possible inconveniences.
Hello Adrian,
You're welcome! :-)
Hello Adrian,
No problem. There can be more things to be noted, for example, I am not sure if the plugin that you try to use allows HTML bodies. If so, that's ok. If not, the server side come again here as a posible best option: for example, using PHP, it's quite easy to prepare HTML and plain text emails, and, as I say before, directly send the emails, and not relies on a thirdparty app and the user intervention.
It's more or less clear that I love the server side? :-) Well... certainly the server side allows to do things that we can do in the client side, so, must be an option to consider! Of course, if your choosed plugin support HTML bodies, or that is just what you wanted, that's not a problem: just choose the best solution for your needs.
Hello Adrian,
If what we get is the HTML of the table, we can get it using a bit of Javascript/jQuery like the below:
However, I am not sure if something like that can work, because, that HTML contains some stuff that may cause some problems in the E-Mail's body, or the HTML table may don't appear exactly like you wanted. You can try it, Adrian.
If that do not work, maybe you can iterate over the Report's Data variable, and compose the HTML table / E-Mail body by yourself: this allows to take care about the HTML that we place in the E-Mail's body.
Another possible way is to use the app's server: if we have the Report's Data / Records available in the server's side (for example, if they come from a database), or just by sending the data that we need to use, we can send the E-Mail from the server side.
Probably the plugin that you refer (who work in the client side) do not really send the email, but just prepare it. Well, the server side solution is more directly, that is, a server can directly send the emails, without the user intervention.
Please, consider the above and put here any further questions that you can have, Adrian.
Hello to all,
No problem at all AJ2018, can not compete with David :-) as I am quiet a newbie myself, but Glad that I could be of help
Any help is appreciated here! :-)
Hello Amin,
I am not quite sure, but, what we can share is the HTTP Client control, because is a non visual control, however, supose we update a "Report 1" from the HTTP Client Success event... supose that "Report 1" do not exists in the view in which we are when the Success event is fired... then yes, we have a problem, because we are trying to set something in a visual control which is not visible.
In few words, we can use the HTTP Client control from various views... we can use the [App.CurrentView] to determine in which view we are, etc. However, I think the best way to load a "Report 1" control placed in a "View 1", is to execute an HTTP Client control placed in that "View 1". And, in principle, there is no problem to execute this HTTP Control everytime the "View 1" is shown.
But what happen if we have another Report in the same view or in another view? Well... in fact there is no problem to use one HTTP Client control per report, since, in principle, there is no limits in the number of HTTP Controls that we can use. In this way we may have a little more of control... in the sense that every HTTP Client is intented to update controls than exists in the same view than the HTTP Client control.
Hello to all,
In fact, we can place an HTTP Client in View1 and use it from View2... without the Master view... the point is that, if we modify some element in the HTTP Client events (Success or Error), that element must exists in the view in which we are. On the other hand, there is any problem to use any number of HTTP Client controls, so, if we wanted, we can place one in every required view without problems.
Hello to all,
Here is a new DecSoft App Builder release, with the below changes, fixes and enhancements:
Everybody can read the DecSoft support forum for learning purposes, however only DecSoft customers can post new threads. Purchase one or more licenses of some DecSoft products in order to give this and other benefits.