• WSJayden

    WSJayden

    @wsjayden

    Viewing 15 replies - 31 through 45 (of 173 total)
    Author
    Replies
    • in reply to: Changed coding standards for VB.NET (Office97 et a #879926

      I have found that making sure all my VB6 arrays are 0 based (ie. dim a_strThing(0 to 3) / dim a_strThing(3) … rather than dim a_strThing(1 to 4)). Because VB.NET doesn’t support anything but 0 based arrays, I found if you used anything but this, your program logic could go a bit haywire in places. This is just one little thing amongs the multitude of things that you can do to make life easier, but it is one thing that I found sped up “converting” code.

      Incidentally, I “converted” a medium sized application from VB6 to .NET and I was surprised at how little I needed to initially change to get it working (although I have since changed a great deal to ‘optimise’ it for .NET).

      J

    • in reply to: Codified Coding Standards (VB.NET/C#.NET (1.0/1.1/2.0)) #879921

      Don’t forget that Microsoft are the people that also in most of their examples prefix ALL variables with ‘my’ (myDataAdapter, myString, myObject).

      I ask you is that a good example to be setting? and more to the point? Is that someone we should be listening to for advice about nomenclature?

    • in reply to: Codified Coding Standards (VB.NET/C#.NET (1.0/1.1/2.0)) #879922

      Don’t forget that Microsoft are the people that also in most of their examples prefix ALL variables with ‘my’ (myDataAdapter, myString, myObject).

      I ask you is that a good example to be setting? and more to the point? Is that someone we should be listening to for advice about nomenclature?

    • in reply to: Codified Coding Standards (VB.NET/C#.NET (1.0/1.1/2.0)) #879920

      To follow on from my last post, but on a slightly different tangent (hence the seperate post), I am using Hungarian notation and we have enshrined that in coding standards at my workplace. However, we have opted to use standard hungarian notation for ‘common’ variables and controls, ie such as string, integer, long, byte, textbox, combobox etc. We have drawn a line in the sand though, and only use the Prefix of ‘obj’ for the plethora of other not-so-common variables and objects, ie. DataReaders, DataAdapters etc.

      The rationale behind this is that the not-so-common occurence of these objects means that we can use the description of the object type as part of the name, with an adjective to describe seperate functions of the same variable within a procedure…

      objDataAdapter
      objDataReader

      or

      objDataReaderPatient
      objDataReaderEpisode

      The only dilemma that I have had is to work out how to differentiate a truely OBJECT data type … if in fact I need to?

      What this means is that the hungarian notation ‘dictionary’ if you like is small enough to not have to worry about continually referencing obscure data types or objects in documentation, which in .net, due to it’s rich object model, could be onerous, but to focus on making the code readable and understandable at a glance.

    • in reply to: Codified Coding Standards (VB.NET/C#.NET (1.0/1.1/2.0)) #879919

      To follow on from my last post, but on a slightly different tangent (hence the seperate post), I am using Hungarian notation and we have enshrined that in coding standards at my workplace. However, we have opted to use standard hungarian notation for ‘common’ variables and controls, ie such as string, integer, long, byte, textbox, combobox etc. We have drawn a line in the sand though, and only use the Prefix of ‘obj’ for the plethora of other not-so-common variables and objects, ie. DataReaders, DataAdapters etc.

      The rationale behind this is that the not-so-common occurence of these objects means that we can use the description of the object type as part of the name, with an adjective to describe seperate functions of the same variable within a procedure…

      objDataAdapter
      objDataReader

      or

      objDataReaderPatient
      objDataReaderEpisode

      The only dilemma that I have had is to work out how to differentiate a truely OBJECT data type … if in fact I need to?

      What this means is that the hungarian notation ‘dictionary’ if you like is small enough to not have to worry about continually referencing obscure data types or objects in documentation, which in .net, due to it’s rich object model, could be onerous, but to focus on making the code readable and understandable at a glance.

    • in reply to: Codified Coding Standards (VB.NET/C#.NET (1.0/1.1/2.0)) #879917

      I have a book (Microsoft Press) on Coding Standards for .NET at work, I will post it’s details tomorrow. I found it a good foundation and discussion more than anything, and it helped me put some things straight in my own mind.

      I guess the largest departure (or rather recommended departure) from VB6 to .NET with regard to coding standards I have struggled to work out the ‘right’ answer for is that of notation of variables. Interestingly the Microsoft Press book endorses Hungarian notation for .NET and briefly discusses it.

      After much thought, some discussion with fellow developers and some reading, I have come to the conclusion that using Hungarian notation is a better idea than not. Basically, when I am reading through code (note: I do mean reading and not ‘stepping’) i don’t want to have to hover over ever variable to work out what it’s data type is…this is slow and counter-intuative. VB6 has not much of a different feature where we could have done away with Hungarian notation on the same grounds, simply by pressing SHIFT-F2 and SHIFT-ALT-F2 … but we didn’t do this and do away with Hungarian notation… ? Why … because it doesn’t help with ‘reading’ code.

      At the end of the day, a standard is a standard. I guess that there are good and bad things bout using or not using Hungarian notation. To me, the MOST important issue is that your company or team has a standard , it is well defined, everyone sticks to it (unless there is a good reason not too) and the standard is DOCUMENTED.

    • in reply to: Codified Coding Standards (VB.NET/C#.NET (1.0/1.1/2.0)) #879918

      I have a book (Microsoft Press) on Coding Standards for .NET at work, I will post it’s details tomorrow. I found it a good foundation and discussion more than anything, and it helped me put some things straight in my own mind.

      I guess the largest departure (or rather recommended departure) from VB6 to .NET with regard to coding standards I have struggled to work out the ‘right’ answer for is that of notation of variables. Interestingly the Microsoft Press book endorses Hungarian notation for .NET and briefly discusses it.

      After much thought, some discussion with fellow developers and some reading, I have come to the conclusion that using Hungarian notation is a better idea than not. Basically, when I am reading through code (note: I do mean reading and not ‘stepping’) i don’t want to have to hover over ever variable to work out what it’s data type is…this is slow and counter-intuative. VB6 has not much of a different feature where we could have done away with Hungarian notation on the same grounds, simply by pressing SHIFT-F2 and SHIFT-ALT-F2 … but we didn’t do this and do away with Hungarian notation… ? Why … because it doesn’t help with ‘reading’ code.

      At the end of the day, a standard is a standard. I guess that there are good and bad things bout using or not using Hungarian notation. To me, the MOST important issue is that your company or team has a standard , it is well defined, everyone sticks to it (unless there is a good reason not too) and the standard is DOCUMENTED.

    • in reply to: mde database (access 97/access2002) #867591

      The tables in an MDE database are viewable. You may have to hold down the shift key as you open the database file?

      Only forms, reports, modules etc can’t be accessed in an MDE (compiled) MS Access database.

      Hope this helps.

    • in reply to: mde database (access 97/access2002) #867592

      The tables in an MDE database are viewable. You may have to hold down the shift key as you open the database file?

      Only forms, reports, modules etc can’t be accessed in an MDE (compiled) MS Access database.

      Hope this helps.

    • in reply to: Conversion Problem (VB.Net) #867589

      I would guess that the instructions you are referring to mean to add your OWN property to the form.

      Public Property IsInitiliasing …

      Or something similar. Even just a module level variable would probably do the trick.

      Regards

    • in reply to: Conversion Problem (VB.Net) #867590

      I would guess that the instructions you are referring to mean to add your OWN property to the form.

      Public Property IsInitiliasing …

      Or something similar. Even just a module level variable would probably do the trick.

      Regards

    • Not that I can think of – but I’m not an expert.

      For interests sake, I have discovered if you make the account a System Admin, then the wizard functions fine. The wizard is likely using some stored procedure or something somewhere in a system database i would think…don’t know what for though, or why it wouldn’t need to use said stored procedure for a SELECT but would for an UPDATE, INSERT or DELETE?

      I will just give that user ‘Sys Admin’ rights while I am developing, although not ‘best practice’ it will save me a lot of headaches, I will then put them back to a standard user once I have finished development.

      Cheers

    • in reply to: SQL Server (XP/2K) #697108

      The ‘files’ that SQL Server (MSDE) uses, should probably be installed in C:Programe FilesMicrosoft SQL ServerMSSQLData. You do not want to play around with these files unless you really know what you are doing I would guess.

    • in reply to: SQL Server (XP/2K) #697107

      You can use a number of things to ‘view’ sql server tables.

      The easiest for you is to probably use MS Access. Create a new MS Access Project (.adp) file. You will need to enter the appropriate server name (the name of your computer) and the like, including the SQL Server Database Name. Once you have done this, you will be able to view the SQL Server objects in the MS Access Project (.adp) file.

      You could also use Enterprise Manager, or if you wanted to get really tricking, search for a command line tool, called osql.exe, you can type in the commands manually using this (ie. select * from tblName).

      I think MS Access would be your best bet for basic functionality.

    • Hi Charlotte,

      Yes , other people are in the database, using it when I am also trying to access it with ADO. Those users are using the Access 2 front end application.

      What alternative method of accessing it via VB6 would be better do you think? Using DAO instead?

      J

    Viewing 15 replies - 31 through 45 (of 173 total)