Foundations

Module one. Your first Wisej.NET application. We'll build a small screen that asks for a name and displays a greeting. This introduces the basic workflow: design the interface, handle an event, and test the result in a browser.

Start in Visual Studio and choose Create a new project. Wisej.NET uses the familiar project workflow, with templates that provide the initial application files. The interface will run in the browser, while our event code runs on the server.

Search for Wisej.NET. This walkthrough uses the Wisej.NET 4 Web Application template with C#. Select that template and continue. If it is missing from your own installation, check that the Wisej.NET extension and project templates are installed before proceeding.

Choose a project name and a location, then click Create. Visual Studio generates the project and its starting window. Look at Solution Explorer: this is where you'll find the application files and return to the window as you build the screen.

Build the project before opening the designer. The build compiles the application so the designer can load its types. Watch the Output window and wait for Build succeeded. If the build fails, resolve the errors before continuing with the layout.

In Solution Explorer, double-click Window1 to open its design view. This is the surface where we arrange the controls. The designer records their layout in Window1.Designer.cs. Keep that generated file under the designer's control; write the screen's behavior in Window1.cs.

Drag the controls from the Toolbox onto the window. A label asks for the user's name, a text box accepts the answer, and a button will run the greeting. Add a second label for the result. Each control now has a clear role in the interaction.

Set each control's Name and Text in the Properties window. Name is the identifier used by your code; Text is what the user sees. Use txtName for the input, btnSayHello for the button, and lblStatus for the result. The heading label is lblTitle.

Double-click the button to create its Click handler. Read txtName.Text and trim the spaces. If the result is empty, set lblStatus.Text to a message asking for a name, then return. Otherwise, put the greeting in the label. Validation happens before the successful response.

Press Start to run the application locally. When the browser opens, enter a name and click Say Hello. The Click handler runs and the result label displays the greeting. You have connected a visually designed screen to C# code and seen the response in the browser.

In this lesson, we will build a Wisej.NET dashboard in the Visual Studio Designer. We will arrange its controls, give them meaningful names, and connect a button to a Click handler. You will see which work belongs in the generated layout and which belongs in your own code.

Open DashboardWindow in design view. This window will collect the service status, commands, and event history in one place, so users can understand the result of each action without changing screens.

Use the designer to arrange controls, the Toolbox to add them, and the Properties window to configure them. These three surfaces work together: select a control on the canvas before changing its properties.

Add a heading and a separate status label, then place the three service labels inside a panel. The panel groups related information, while the overall status remains easy to find above it.

Add Start, Stop, Reset, and Refresh buttons, followed by the event list. The buttons initiate actions; the list explains what happened. Keeping that history visible makes repeated actions easier to follow.

Set Text for the words the user sees and Name for the identifier your code uses. A name such as btnStart should identify the control’s purpose, so its event handler is easy to locate later.

Double-click Start to create its click handler. Update the status labels there and call a helper to append the event. Reusing the logging helper keeps the event history consistent across all four commands.

Write behavior in the window’s regular C# file. The designer maintains its own generated file for control creation and layout. Keeping those responsibilities separate prevents a later design change from overwriting your handwritten logic.

Run the project and wait for the browser to open. The screen you designed is now the user interface of the running application. Check its initial state before testing the buttons.

Click Start and watch the three service labels change to Online. The overall status becomes Running, and the event list records the action. Those visible changes should agree with one another.

Click Stop next. Each service becomes Offline, and a new entry records the stop. Keeping the earlier start entry lets the user see the sequence of actions rather than only the current state.

Click Reset to return the demonstration to its initial state. The previous log entries disappear and the status becomes Idle. Record the reset itself so the empty history has an understandable explanation.

Finally, click Refresh to read the current status again and add a log entry. Refresh checks the state; it does not mean Start or Reset. Distinct commands should produce distinct, understandable results.

We will build a shared shell for the application so every page uses the same navigation and layout. The header, navigation area, content region, and status bar each have a clear role. Centralizing page changes also gives us one place to reflect the current user's permissions in the navigation.

Watch the outer frame stay in place while the central view changes. This shared shell gives each feature a consistent home and avoids rebuilding navigation on every screen.

Arrange the header, navigation, content area, and status bar as separate regions. Each has a different responsibility: orientation, choosing a feature, doing the work, and reporting the result.

Dock the header at the top, navigation on the left, and status bar at the bottom. Let the content fill the remaining space so resizing preserves the overall structure.

Route every navigation button through NavigateTo. A single method can apply the same page-switching rules consistently; separate implementations in each button would drift as features are added.

Follow NavigateTo through the page change: remove the previous content, load the selected view, then update the breadcrumb and status. The navigation feedback must describe the view actually displayed.

Settings remains visible to the Support Agent, but Save is disabled in this demonstration. This illustrates a permission in the interface; the later authentication work must enforce the actual authorization too.

The shell now separates shared navigation from reusable feature views. When adding a page, connect it through the same navigation method and check that its location and status remain clear.

We will display a list of tickets in a DataGridView and connect the selected ticket to the detail controls. A service will provide the data, while the screen coordinates selection and display. This separation keeps database and business decisions out of the user interface event handlers.

Build the ticket editor around a shared data model rather than copying values between unrelated controls. Binding connects the selected record to the screen, while the service handles ticket operations.

Put the detail fields on the left and let the ticket grid fill the right side of the split container. Users can select a record and inspect its details without leaving the list.

Ticket describes the fields in a record. TicketService provides operations such as loading and saving. The screen calls those operations instead of becoming the place where persistence rules are implemented.

Connect the list and grid through a BindingSource, then bind the detail fields to that same source. Sharing the current record keeps Title, Status, Priority, and Description aligned with the selection.

Save through TicketService first, then notify the binding system with ResetBindings. Refreshing the display is separate from saving the data: an updated grid alone does not prove persistence succeeded.

Run the editor and select different ticket rows. Watch the detail fields follow the selection through BindingSource. This confirms that the grid and editor share the same current record.

Change the selected ticket’s status and click Save Ticket. Follow the operation into the service and back to the refreshed grid. The visible row should now reflect the value you saved.

Keep the model, service, and screen responsibilities distinct. When a value looks wrong, this separation gives you a useful question: is the record wrong, did saving fail, or is the display stale?

We will use one dialog to create a ticket or edit an existing one. The dialog checks required fields and reports success only after the operation succeeds. Ticket operations remain in the service layer, so the same rules apply whichever screen opens the dialog.

Create one focused dialog for entering a ticket and editing an existing one. Give Save and Cancel distinct outcomes so closing the dialog never silently implies that data was accepted.

Group the ticket fields inside the dialog and keep Save and Cancel easy to find. The dialog should collect one coherent change, with enough information for the user to review before accepting it.

Initialize the same dialog differently for each workflow. New starts with empty input; Edit loads the selected ticket. Reusing the layout keeps the two workflows consistent without confusing their starting states.

Run ValidateForm before returning an accepted result. If required values are missing, keep the dialog open. DialogResult.OK should communicate valid accepted input, not merely that the Save button was pressed.

Open New and try saving without a title. The message identifies the missing information and the dialog stays open, giving the user a chance to correct the input without restarting the operation.

Complete the required fields and accept the dialog. The parent then calls TicketService and refreshes the grid. Follow that order so the user sees the result of the accepted, saved change.

Select an existing ticket and open Edit. Its current values should appear in the same dialog. Change a field, save, and verify that the corresponding row updates rather than creating another ticket.

Use the same sequence for both workflows: validate, accept, save through the service, and refresh. Keeping those stages explicit makes cancellation and validation failures easier to handle without accidental writes.

We will run a simulated export or import in the background and show its progress without blocking the interface. Each connected user will keep their own operation state. We will also handle failures with a useful message for the user while keeping internal error details out of the screen.

Use the export and import demonstration to follow a job over time. A responsive screen needs more than a progress bar: users must understand whether work is running, finished, cancelled, or failed.

Keep the start commands, cancellation, progress, and log visible together. They answer different questions: what can I do, how far has the job progressed, and what has already happened?

In RunJobAsync, await each step and report its progress. Use the error handler for failures and the finally block for cleanup, so the interface can leave its busy state even when work fails.

Start Import and watch the controls change while the job runs. Disable commands that would conflict with the active operation, but keep progress and feedback available so the user can follow the work.

Keep progress and other user-specific values in the current session. A static field is shared across users, so storing one person’s job state there could make another person see or change it.

Enable Simulate Error and run the job again. Keep diagnostic details in the log for investigation, while the user receives a brief safe message. Technical exception details should not become public error text.

The button initiates the operation, the job performs the work, and the screen reports its state. Keep these roles separate so success, cancellation, and failure can all return the interface to a usable condition.

We will update the dashboard's appearance using a built-in theme, cards, and consistent navigation. The existing services, validation, and data binding will continue to do their jobs. This lets us improve how users read and navigate the screen without rewriting the application's business behavior.

Modernize the existing screen without rebuilding its behavior. A Wisej.NET theme supplies consistent visual choices; layout and navigation improvements then make the application easier to understand.

Make the page title easy to identify, group related metrics, and place commands beside the content they affect. Visual hierarchy should help users decide where to look and what to do next.

The theme selector changes Application.Theme.Name, while SetActiveButton marks the selected navigation item. Treat appearance and location as separate concerns so users still know where they are after switching themes.

Switch between the built-in themes and compare the same controls. Their appearance changes while the workflow remains the same. Check readability and active states rather than judging the theme only by its colors.

Review the finished dashboard as a whole. Consistent spacing, cards, and navigation should support the existing data binding and validation. A visual refresh succeeds when the familiar workflow becomes clearer.

We will add a small JavaScript status visualization to a Wisej.NET screen. Native controls will still handle the ordinary interaction, and C# will own the data, decisions, and logging. The widget will display the values it receives, giving us a specialized visual without creating a second source of application state.

Add a small JavaScript visualization to the existing Wisej.NET application. Keep the main logic in C# so the extra visual does not become a second owner of the application’s decisions.

Use native Wisej.NET labels, buttons, and logging for ordinary interaction. Introduce a Widget only for the specialized visual. This keeps the integration focused instead of replacing controls that already solve the problem.

Send the widget only the display values it needs: status, ticket counts, and system load. C# remains responsible for those values; the browser visualization presents them without receiving unrelated server data.

The button handler updates the native labels and sends the same data through UpdateWidget. Using one result for both presentations prevents the text and visualization from describing different states.

Click Refresh Server Data and compare the labels with the widget. They should change together from the same server operation. If they disagree, inspect the data passed across the integration boundary.

Try Healthy, Warning, and Critical in turn. The C# events update the visual state and record the change. The event history helps explain why the widget has its current appearance.

We will review the application before packaging it for release. Configuration, secrets, logging, and permissions each need an explicit check. The release workflow will use those checks to decide whether the package is ready, while keeping confidential details out of user-facing messages.

Use the review screen to collect evidence before release. Configuration, security, and deployment checks belong in one repeatable process, so readiness depends on completed checks rather than a reassuring impression.

Record the environment, hosting target, version, and reviewer first. These details identify exactly what is being reviewed; a completed checklist for one environment does not automatically cover a different release target.

Work through the required configuration checks separately from optional notes. A note can explain an exception, but it should not make a missing required check disappear from the readiness decision.

Keep secrets and detailed exceptions out of the review display. Show a safe summary and leave diagnostic details in server logs, so the review package can be shared without exposing credentials.

Separate readiness from permission. Required checks determine whether the review is complete, while a role check determines who may create the package. Passing the checklist does not grant the user additional authority.

Complete the remaining required items and watch the count reach nine out of nine. The status changes to Ready for review. That means the checklist is complete, not that deployment has already occurred.

Create the review package and inspect its summary, including known issues and rollback information. A useful handoff tells the reviewer what is ready, what remains uncertain, and how to recover if release fails.

Module ten. Build the Wisej.NET mini helpdesk. This capstone brings the course together in one application. We'll follow its navigation, ticket workflow, and supporting screens, then look at what makes the project ready for review and deployment.

Start with the completed application and follow its navigation shell. The separate course examples now share one layout, so users can move between features without learning a new navigation pattern each time.

Follow Tickets, Customers, and Jobs through their main interactions. Grids present records, dialogs collect changes, and background jobs report progress. After each action, check that the visible result explains what actually happened.

Trace a ticket change across its responsibilities. The dialog validates input, TicketService handles the operation, and the grid presents the result. Consistent labels and status messages connect those stages for the user.

Use Deployment and Architecture to explain the application beyond its screens. Review configuration, security, and logging, then trace data through the service layer. A working demonstration should also make its organization understandable.

Finish with Code Review and Next Steps. Check purposeful names and clear responsibilities, then record remaining production work. The capstone demonstrates a working application while making unfinished work and design decisions explicit.