All Answers

Hi Edmond,

thanks. This is logged as WJ-8356 and a fix will be included in the next Wisej release.
We´ll inform you when it´s available.

Best regards
Frank

Hi Tiago,

to determine the target of a Drag/Drop operation, please take a look at DragEventArgs.DropTarget

Hope that helps.

Best regards
Frank

This issue is fixed and I have updated the FullCalendar source code in /extensions. The next build will include the precompiled component.

No. It’s impossible to handle inner elements in an iframe from a different origin. If the iframe (WebBrowser control) is from the same origin you ay be able to achieve what you want but it must be done on the client in javascript.

Hi David,

The themes don’t add any padding in the buttons. Make sure that the button you create doesn’t have AutoSize = true, it should be false.

The 3px left border when focused in set in the theme. But its done to work with the inner textfield and when focused it reduces the inner padding in the TextBox with the result of not shifting the content. The problem is probably that you are adding a button as a child of a TextBox docket to the left?

Wisej has a system of tool buttons that can be added to most controls to achieve exactly what you want to achieve without having to create child controls. Did you try the Tools collection of the TextBox? All editable controls and most complex controls support tool buttons.

Best,

Luca

Hi,

What is the purpose of having a textbox as a header? I can’t imagine a scenario (may be a filter? – but that would be under the header, wouldn’t it?) and i’m always very intersted in new ideas for user interface.

Best,

Alex

Hi Angelo,

thanks, I could reproduce and have logged issue WJ-8354 for it.
We´ll inform you when a fix is available.

Best regards
Frank

I don’t believe that the app does any modal operations.  It doesn’t show any dialog boxes or anything.

Here’s the process:

• the app displays a panel with a toolbar and a bunch of labels and textboxes, the toolbar buttons have keyboard shortcuts
• the app sets focus to the toolbar
• the user types “c” which triggers the “consult” toolbar button
  • this operation basically lets you type stuff in that will be used to query the database later
• the app rebuilds the toolbar with accept/cancel buttons
• the app sets focus to the toolbar
• the app enables all of the textboxes
• the app sets focus to the first textbox
• the user types things in the textboxes
• the user types “esc” which triggers the “accept” toolbar button
• the app disables all of the textboxes
• the app queries the database for the values supplied in the textboxes, gets a result set and populates the textboxes with the values from the first matching row
• the app rebuilds the toolbar with the original set of buttons
• the app sets focus to the toolbar

At this point, the user should be able to type “m” to trigger the “modify” operation, but the entire app lost focus somewhere after the user hit “esc”.

I’m not 100% sure about exactly when “the app disables all of the textboxes” step is done.  That step might be out-of-order, but it’s definitely not done after the final toolbar-rebuild/focus.

I can email you a link that you can use to access the app if you want to look at it directly.  Just let me know.

Thanks!

Hi David,

are you doing any modal operations before the focus is lost ? Can you please describe the situation/operation where this problem occurs a bit more in detail ?

Best regards
Frank

Thanks David,

I have logged issue WJ-8352 for it and we will inform you when it´s fixed.

Best regards
Frank

here is a full test sample

here is the designer to show how i have the code done.

THANK YOU!

I must have scrolled through the properties 100 times looking for that, and I never guessed the right words to ask google.

Hi David,

you can show/hide that button by setting the property “ShowColumnVisibilityMenu”.

Best regards
Frank

Hi Luca,

I remember reading something about Wisej optimizing the communication but I didn’t think this feature (it’s a feature indeed) was the reason for this behaviour. I browsed all DGV’s properties and methods looking for some option like DataBindingNeedDefaults or  DataBindingLoadDefaults. So I guess there will be some option to change this behaviour. Nice to know.

Hi Tiago,

This “feature” is by design. Winforms creates and destroys the new automatic row every time it gains/loses the focus. Since Wisej has to also try to optimize the communication between the client grid and the server data model, it creates the new row once when the edited values are committed.

However, I see your point and I think we can use the default values of the BO. Will log and hopefully fix quickly.

Best,

Luca

Hi Tiago,

thanks for your suggestion that I have logged as WJ-8351.
We will change both default values and also add a warning to the next release notes.

Best regards
Frank

Hi Levie,

I have tried on my Iphone 6 with our ProgressSample: http://demo.wisej.com/ProgressSample
and it seems to work ok. Can you please try that one on your device ? What device is it ?
Do you observe this behavior with a standard Wisej textbox ?
If not, any chance to share a link or some code snippet ?

Thanks in advance !

Best regards
Frank

Hi Andi,

what you see is the same in WinForms. You also need to change the CurrentRow. While this property is readonly you have to change it by setting the CurrentCell property.

Find some information here: https://social.msdn.microsoft.com/Forums/windows/en-US/47e9c3ef-a8de-48c9-8e0d-4f3fdd34517e/datagridview-select-row-programatically?forum=winformsdatacontrols

Adding the following code to your sample works as expected:

dataGridView1.CurrentCell = dataGridView1.Rows[index + 1][“Column0”];

(Column0 is just a sample name).

Best regards
Frank