Re: External References to Form Elements & Menu Shortcuts

  • From: "RicksPlace" <ofbgmail@xxxxxxxxx>
  • To: <programmingblind@xxxxxxxxxxxxx>
  • Date: Sun, 28 Mar 2010 06:23:39 -0400

OOPS. The variable name in the code blocks should be Globals.CurrentTicker not 
just Globals.Ticker. Sorry, I typed from memory, a bad thing for an old fat 62 
year old blind guy to do too often. But, the idea is correct. Define a global 
variable of any kind, Then move values into and out of that variable from any 
form. You can store Objects as well as simple variables. I have stored Tables, 
Arrays and other things like that. If you have Subroutines of code you want to 
execute from several forms put them in a class as above but not in the Globals 
Class. I think you can make them static. Otherwise you just instantiate the 
class and then have access to the class's functions, subroutines, variables and 
properties as if they were loaded into the code for the form you are working 
in. This is pretty much related to what they call OOP, Object Orientated 
Programming, techniques. And is how programming is done in most languages today 
including Vb.net and CSharp as well as Java and JavaScript. Again, let me know 
if you want to dig into it a little more.
Rick USA

form. Then I can open or close or Dispose the Instances 
  ----- Original Message ----- 
  From: RicksPlace 
  To: programmingblind@xxxxxxxxxxxxx 
  Sent: Sunday, March 28, 2010 6:10 AM
  Subject: Re: External References to Form Elements & Menu Shortcuts


  Hi Don: First, accessing the control values across pages is doablre but can 
get messy as you have seen. As for the reference statements to include the 
variious modules, VB.net uses the Imports Statement rather than the Using 
Statement just above the line where the class begins.
  Imports System
  Imports System.IO
  Public Class MyClass
  ' Some Code
  End Class
  To keep my apps cleaner when they are going to be big I add a Folder to the 
project called App_Code. Inside this folder I add other folders and, or, files. 
One of them is called Globals.vb.
  Now, I have a class like:
  Public Class Globals
  ' Some Code.
  End Class
  Inside this class I add static variables to hold data I want to pass around 
to various forms.
  Here is one of them:
  Public Class Globals

  Public Shared FilteredTickerList As ArrayList= Nothing 

  Public Shared CurrentCoIndexTable As DataTable

  Public Shared CurrentUser As String = "Richard"

  Public Shared CurrentPortfolio As String = ""

  Public Shared CurrentTicker As String = ""

  Public Shared LoggerPath As String = 
"c:\FinDir\FinDir\ReportsDir\GeneralLog.txt"

  Public Shared YahooCsvLogPath As String = 
"c:\FinDir\FinDir\ReportsDir\YahooCsvLog.txt"

  Public Shared NumNull As Integer = -999999999

  Public Shared FatelError As String = "FatelError"

  Public Shared CallingModule As String = ""

  End Class

  Now, in my Form`1 code file I might have a TextBox control tbTicker that 
captures a ticker symbol from a user. Now, I want to know what ticker the user 
entered in that text box in other forms. Instead of referencing that root 
form's TextBox control directly I just move the value into the Ticker variable 
in the globals:
  Globals.Ticker = tbTicker.Text
  Then I can get that value, or modify it, from any form in the project by:
  Dim TheTickerSymbolSelected As String = _
  Globals.Ticker. Or you can display it like:
  MessageBox.Show( "The current ticker is " & Globals.Ticker)
  You do not have to instantiate the Global variables because they are defined 
as Static. That makes them available to use just like a variable inside any 
code block you are working in by just putting the name of the class followed by 
a period followed by the variable name as defined in the class. If this is all 
new to you let me know and I will help you get it set up. You might also 
encounter a similar situation when you try to open, close and keep track of 
which forms are displayed. Remember, you can not close a form and still access 
it's embedded controls so breaking out the values and, or, any data you want to 
pass around is a good idea to keep things less complex and more flexible in the 
long run.
  Hope this helps and just ask if you want to get a step by step which I will 
be glad to do on or off list.
  Rick USA
  class to the project
    ----- Original Message ----- 
    From: Donald Marang 
    To: programmingblind@xxxxxxxxxxxxx 
    Sent: Saturday, March 27, 2010 10:07 PM
    Subject: Re: External References to Form Elements & Menu Shortcuts


    I am not sure about conventional naming standards for forms in object 
oriented land.  This is a Windows Forms Application.  I had named the main 
window, which is a class I believe.  So my main window, named "dcQuickOCRForm" 
(the 'd' is for Dialog and the 'c' is for Control).  the last part "Tecxt" is 
the property that contains the text of the TextBox Control, " tcFilename" ('t' 
is for Textbox and 'c' is again for Control), to type in and display the 
filename.  My issue is that I now pulled code out of the main code file for the 
dcQuickOCRForm.vb file.  I now have this code in different subroutines (Sub) in 
separate module files.  I currently need to provide all three components.  I 
think what I want to do is place a "Using dcQuickOCR" statement within the 
module file.  Is this the correct way to do this in VB?  Does it require an 
"End Using" statement?  Is VB different than other languages in this respect?  
It just seems like it would be faster and less cumbersome as well as less 
confusing than identifying each level each time.  Would this call go inside 
each Sub block in this file or once just after the Module declaration at the 
very top?  

    This is a reference to an object property which contains the name of the 
image file on which to perform the OCR.  If performing OCR on a screen image 
from the clipboard, the program first writes the image to a temp TIFF file 
because I think the MODI object calls only work on a file.  

    For some reason, I did not provide a similar naming convention yet to menu 
components.  

    Don Marang


    From: RicksPlace 
    Sent: Saturday, March 27, 2010 8:22 PM
    To: programmingblind@xxxxxxxxxxxxx 
    Subject: Re: External References to Form Elements & Menu Shortcuts


    Hi: I don't get this file path. When I do code blocks I create them inside 
classes which I usually add to a project folder. Is this a file path or the 
name of something?
    dcQuickOCRForm.tcFilename.Text.
    You mentioned you have to put the above in a control, what type of control 
and are you binding to that control or what property of the control is the 
above path located in? 
    Just curious since I did not understand that part of the 
    message.
    Rick USA
      ----- Original Message ----- 
      From: Donald Marang 
      To: programmingblind@xxxxxxxxxxxxx 
      Sent: Saturday, March 27, 2010 9:15 AM
      Subject: External References to Form Elements & Menu Shortcuts


      Thanks everybody for the many tips!  My program has come a long way due 
to your help.  

      For now I think I will just distribute the executable, a Desktop Shortcut 
Icon, and some documentation files in a zip file.  The user would need to place 
the files at, "C:\QuickOCR" folder and copy the Desktop Shortcut Icon to the 
Desktop.  If they want to install elsewhere, they would need to change the path 
in the Desktop Shortcut Icon.  

      I have two small areas where I still have some questions.  

      I split out most of the large chunks of code, like the OCR processing, 
into subroutines in modules stored in separate files.  This works well, makes 
it easier to update, and would make it simple to add functionality in the 
future.  One such addition would be adding other OCR Engines.  However, since 
it is not within the main form object code, I have had to supply the entire 
object heirachy in the references to controls, such as 
dcQuickOCRForm.tcFilename.Text.  I looked at the Imports, Namespace, and With 
Visual Basic commands.  I started playing around a little with these, but 
decided to first make the subroutines work.  Could someone enlighten me to 
which command would be appropriate, or what modifier on the main form object 
should be changed in this situation? 

      The other thing that started confuddling me at 2 AM last night was that 
JAWS refuses to announce the shortcuts in the menus.  I added the code to the 
File and Actions menus yesterday.  That was another reason I wanted most of the 
code, like "Perform OCR" as subroutines.  There are visible shortcuts in the 
menus and they work if you know the shortcut key combinations, like Control + O 
for Open image.  I have set the shortcut properties; 
ShortcutDisplayText="Ctrl+O", ShortcutKeys="Ctrl+O", and ShowShortcutKeys=True, 
of the menu items in the property tables for the menu items.  I have tried both 
"Ctrl+O" (contracted spelling) and "Control+O" (all characters) in the 
ShortcutDisplayText property.  Things are displayed on the screen as expected 
and function properly, but JAWS refuses to announce the shortcuts.  JAWS is 
announceing menu shortcuts in all other applications, including Visual Studio 
Express.  What do I need to do to force JAWS to recognize and announce the 
shortcuts?  

      Don Marang

Other related posts: