Thanks Cris !
Logged as WJ-8206, fixed in the latest Wisej release (1.3.59).
Best regards
Frank
Excellent! I can confirm that 1.3.58 resolves the JSON/TextBox and ToolBarButton issues I was having. I also see that WJ-8202 fixes a problem that I thought I noticed, but wasn’t sure of. Thanks guys!
Hi Pierre,
WJ-8194 is fixed in the latest Wisej release (1.3.98).
Best regards
Frank
Hi David,
we have added Luca’s suggestion (WJ-8205) to the latest Wisej build (1.3.58).
Best regards
Frank
Sorry Andrew,
my mistake:
You just need to set Toolbar.ShowToolTips = true. It´s false by default.
Best regards
Frank
Thanks Andrew,
I see the problem now. I have logged that issue as WJ-8204.
We´ll inform you when it´s fixed.
Best regards
Frank
Hi Frank,
Thank you for trying that. I’ve modified your example and attached. The standalone button tooltips work fine (i.e. the 2 buttons you had added). When you add a button to the toolbar using the Buttons property or Edit Buttons in the designer and set the tooltip text on a button, that’s the part that doesn’t appear to be working at runtime.
Thanks for the tip. I discovered the problem. A bug somewhere else caused the report to be garbage – random bytes. So, the app was appending random bytes to the TextBox.Text and it threw that error when the app appended some control character.
So, is the app responsible for making sure that the data written to a TextBox is clean? It seems like I can write anything to a WinForms TextBox, and it will filter out invalid characters.
I was able to update my test program (attached) to exhibit the error. Type a number in the top TextBox, click Go, and it will attempt to write the ascii character for that number in the bottom TextBox. Any numbers below 32 (control characters) cause the error.
The app revealed a second issue too. If I type a number in the top text box, I have to click on Go twice to get it to fire. Once to set focus to it, and a second time to trigger the button. This may or may not be a bug. WinForms might do the same thing, but I don’t think so.
That error comes from the JSON parser in the browser, you can’t catch in on the server. I’d suggest to use Chrome, open tools with F12, go to Source, at the top right enable the “pause at exceptions” button and check the checkbox “pause on caught exceptions. Chrome will stop at the line that generated the parser error. Then take the string being parsed and see what is the wrong control character. The control character usually means a wrong escape, like “\n”.
Hi Mark,
I have attached a sample project showing how to use Wisej.Web.Widget directly. As I mentioned in the linked post, there is no need for an extension unless you want to turn a widget into a full fledged Wisej control. In any case, the first step is always to use it directly and get familiar with the widget.
This is the vis.js in Wisej designer. The sample project is attached. Look at the InitScript content, I simply copied and pasted their samples and changed container = document.getElementById(…) to container = this.container.
HTH
Best,
Luca
Of course 🙂
You can
1- Use a PictureBox and assign the Image property to an Image created from the database.
2- Use a PictureBox and assign the ImageSource to an image file name saved from the database.
3- Use a class derived from PictureBox, add “: Wisej.Core.IWisejHandler” and assign the ImageSource to this.GetPostbackUrl(), then implement IWisejHandler.ProcessRequest() as in any handler, the parameter is HttpContext.
4- Create a component on a page (or form), or add “: IWisejHandler” to the page (or form) and then you can pass this.GetPostbackUrl() to any <img src> tag you can place in any control (Label, Button, DataGridViewCell) than has AllowHtml. You can also add parameters to this.GetPostbackUrl() + “&img-name=test”, for example, and have your IWisejHandler.ProcessRequest() return an image depending on the parameters.
And infinite combinations of the above.
Hi Andrew,
trying to reproduce the problem I have set up a very simple sample.
But it works ok. Can you please test it and compare to your code to see if you can spot a difference ?
Thanks in advance.
Best regards
Frank
I have attached an example of how to use Wisej.Web.Widget with the OrgChart and retrieve the data using Wisej WebMethod call.
When you open it in design mode, select InitScript and open the editor. You can see the initialization code (see below).
When in design mode, it will show some simple placeholder data. When running, it will call the GetOrgChartData() method on the parent page and then initialize the chart object using the data received from the server. It will also attach the “click” event on each node and fire the WidgetEvent on the server.
All the code in there depends on the widget you are using.
There are other ways to get the data from the server, but calling the WebMethod allows you also to call different methods, update the data, etc.
In design mode you’ll see the placeholder design data.
Hi Ser,
You don’t need a Wisej extension to use third party javascript widgets. Wisej already includes the Wisej.Web.Widget control that you can add to any container (at design time too). It let’s you import any script and css and run any initialization code. It’s actually a lot simpler than using vanilla html.
We may turn this into a tutorial. But for now, I created a simple sequence of screenshots and a zipped project.
This are the basic steps:
1- Drop a Wisej.Web.Widget control on a container. You can set the BorderStyle, colors, etc.
2- Add the “packages” you want to use. You can refer to a CDN url or to a local url if you host it on your server. You can specify multiple js and css files. Wisej will load them in sequence. Therefore if you have dependencies, place the libraries that load first at the top. In this case we are loading just particles.js.
3- This is the most important step and it depends on the widget/library you are using. It requires knowledge of the library and of javascript in general. Most third party widgets need a DOM Element to wrap. The type of the element depends on the widget, some need a <textarea> others need <canvas>, and some are happy just with a <div>.
Wisej.Web.Widget is a simple <div> and it makes the reference to the DOM Element available to “this.container”. You can use this directly with jQuery or any other library that just needs a DOM element. In other cases you have to create a new one, the most common way is to use this.container.innerHTML = “your html”.
The particles library is happy with a <div> but it needs an id, it cannot use the element directly. Look at the lines in the screenshot below. I assigned an id to the element and then simply initialized the library. The json is copied and pasted from http://vincentgarreau.com/particles.js/.
NOTE: You’d have to do this (and more) with Angular, ASP.NET/MVC, plain HTML, etc.
4- Your are done! Almost actually. When you click OK, Wisej will immediately render the imported widget in the designer. However, in this case, you will not see it because the lines are white and the background is white. Change the background on the widget and you’ll see:
Hit Run and you’ll get your widget running.
You can even receive events, but you’d have to attach to the events fired by the widget and send them to Wisej using
this.fireWidgetEvent(“name”, {data});
On the server, just attach to WidgetEvent. That’s all. 🙂
You can use any CKEditor configuration option in the Options property. For font sizes, “use fontSize_sizes”.
I added this to test: “fontSize_sizes”: “16/16px;24/24px;48/48px;”
Hi Frank,
I guess one could use Sellennium to do just that…
Hi Jim, Guenter, Nic,
TinyMCE extension has been released, see
https://wisej.com/extensions/
Best regards
Frank
Hi Ser,
Wisej applications don´t really need to be secured by a captcha since it´s virtually
impossible for a bot to fill out a Wisej form and press a button.
After all there is no submit action.
Still, we will evaluate some of the solutions that are available and will see if we can integrate one.
Best regards
Frank
Excellent! That javascript worked for me too. Thanks!
Hi David,
I can reproduce but unfortunately it appears to be a bug in Firefox. The problem is not the focus, that is set correctly. Somehow after the print dialog is displayed once, FF appears to re-registers its internal handler or something like that and it handles ctrl-P before our handlers. It’s a really weird thing it does.
The only way I found to make FF behave correctly is to register the keydown event handler very early (too early for wisej) directly in Default.html. Add the script below in Document.html and FF will start acting as it should.
<body>
<script>
document.documentElement.addEventListener(“keydown”, function (e) {
if (e.ctrlKey) {
switch (e.keyCode) {
case 80: // Ctrl-P
e.preventDefault();
break;
}
}
})
</script>
</body>