Thanks, copied and pasted your code and it worked. I'll have to spend some time to read and understand it so I can work with it. It's crazy how much code there is for just typing something in and pressing "ok" or "cancel"
I was able to get what I needed. There are a couple things I would like to improve upon.
For the propertys is there any I can make this an array? I have 5 of these things defining _PartValue1 to 5.
Private _PartValue1 As String = "" Public Property PartValue1() As String Get Return _PartValue1 End Get Set(ByVal value As String) _PartValue1 = value End Set End Property
Private _frmPartValue1 As String Public Property PartValue1() As String Get Return _frmPartValue1 End Get Set(ByVal value As String) _frmPartValue1 = value End Set End Property
And also can you change the font size? I tried Me.label1.font = New Font (arial, 10 ) but said the font wasn't decleared?
It can be done with less code; you could dispense with the properties and just use public variables. The advantage of properties is they give you more control over the access of the variables and allow you to do some validation (not shown in the example code). The disadvantage is: public variables in a form are a lot like global variables; if you run into a bug it can be tricky tracking down what code wrote what value to them. I'm planning a future example that expands on this, I wanted to lay the groundwork in the initial article rather than explaining why we have to re-write the original code to use properties.
I'd suggest using a List of type string rather than an array (lists are easier to work with than arrays). The list of values could be a read-only property of the form; you could then add methods to easily add or remove items from the list.
You can change the font properties of the controls in the IDE. If you want to change them at runtime, you will probably need to fully qualify the names (the NXOpen API may have classes named "Font" or "Drawing") to avoid ambiguity.
Me.Label1.Font = New System.Drawing.Font("Arial", 10)
If you have access to the SNAP API, then you can do what you want with essentially one line of code, like this:
Option Infer On Imports Snap.UI.Input Public Class MyProgram Public Shared Sub Main() Dim s = GetString("Enter text", "Very Simple Dialog", "Input", "Hello") End Sub End Class
The resulting dialog is an NX "block-based" dialog, rather than a Windows form. It looks like this:
To enter several strings, use Snap.UI.Input.GetStrings (plural). It returns the input strings in an array, as you wanted. To enter numbers, use GetInteger, GetIntegers, GetDouble, GetDoubles, and so on. There's also GetPoint, GetVector, etc.
Yeah, that does seem to be a lot simpler. It is nice to know, but I don't have a snap license. I also don't mind learning the long VB way of doing it, because it seems like there is a lot more room for customization. It also seems to be the way computer programmers ( ones that don't use NX) do things.
Also thanks for the heads up on the lists. I thought arrays were the vb way of making lists so I overlooked it.
I replaced my user input with snap in one of my favorite programs:
FindString = InputBox("Find what:", "Rename operations")
FindString = GetString("", "Rename operations", "Find what:", "")
The block based dialog looks better, but <Enter> does nto OK the dialog like the old way. I know that's NX standard behavior, but is there a setting for this in Snap?
> is there a setting for this in Snap?
Sorry, but there isn't. SNAP is just using standard NX blocks to build these little dialogs, so it doesn't have much control over how they behave. But I somewhat agree that, on a dialog with only one entry feld, <Enter> should close it. I'll look into it.
> It also seems to be the way computer programmers (ones that don't use NX) do things.
True. But some NX dialogs do strange and wonderful things (like object selection, highlighting, graphical widgets, etc.) that would be very difficult to replicate with Windows forms.
On the other hand, NX dialogs are somewhat rigid (typically just a collection of "blocks" stacked on top of one another).
So, both WinForms and NX block-based dialogs have their uses.
In this particular case, I'd say an NX dialog is better, because it's simpler to code and it looks like the rest of NX.